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fective  consideration,  definition,  development,  and  integration  of 
cd  training  (ET)  capabilities  for  existing  and  developmental  systems, 
nts  share  the  general  title  of  Implementing  Embedded  Training  (ET). 
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SECTION  1 
INTRODUCTION 


One  major  step  in  developing  an  embedded  training  (ET)  component 
for  a  system  is  defining  the  ET  requirements  (ETRs)  for  the  system. 
ETRs  are  a  first  approximation  to  the  training  content  and  structure 
for  the  ET  component.  The  ETRs  are  the  tasks  and/or  behavioral 
performance  objectives  that  should  be  supported  by  an  ET  component. 
Actual  design  of  an  ET  component  to  meet  the  ETRs  is  a  follow-on 
activity  to  ETR  development. 


The  Iterative  Nature  of  the  ETR  Identification  Process 


It  is  important  to  understand  the  iterative  use  of  the  ETR 
identification  procedures  in  the  system  development  process.  These 
procedures  are  not  intended  to  be  simply  used  once.  They  should  be 
exercised  a  minimum  of  two  times  in  the  process  of  defining  an  ET 
component  for  a  system.  In  some  cases,  where  a  system  matures  slowly, 
or  different  subsystems  mature  at  different  rates,  more  than  two 
iterations  of  the  ETR  identification  will  need  to  take  place. 


Iteration  One:  Preliminary  ETRs 


The  first  use  of  these  procedures  should  take  place  during  the 
pre-Concept  Exploration  phase  of  system  development  (if  the 
conventional  life  cycle  systems  management  model,  or  LCSMM,  is  used)  or 
during  the  Requirements  and  Technological  Base  phase  (if  the  Army 
streamlined  acquisition  process,  or  ASAP,  is  used).  ETRs  defined  at 
this  point  will  probably  be  based  on  early  comparability  analysis  (ECA) 
or  other  estimation  data,  where  required  system  operator  activities  can 
be  defined  only  to  a  task  (or  in  some  cases,  functional)  level.  This 
level  of  detail  will  not  support  identification  of  ETRs  at  the  level 
needed  to  design  an  ET  component  (detailed  behavioral  objectives). 

This  means  that  ETRs  from  the  first  iteration  should  be  considered 
preliminary. 

The  preliminary  ETRs  are  intended  as  an  estimate  of  what  ET  may 
need  to  be  supported  by  a  new  system,  but  probably  are  not  a  sound 
basis  for  designing  the  ET  component.  Thus,  they  must  be  updated  when 
detailed  data  on  the  system  under  development  become  available.  The 
preliminary  ETRs  provide  input  into  the  design  of  the  total  training 
system  concept.  This  concept  in  turn  provides  important  information 
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used  in  preparing  several  requirements  documents  for  the  new  system. 
These  are: 

1.  Jus tif ication  for  Major  System  New  Start  (JMSNS). 

2.  Organizational  and  Operational  plan  (0&0  plan). 

3.  System  MANPRINT  Management  Plan  (SMMP). 

4.  Phase  One  System  Training  Plan  (STRAP). 

5.  Tentative  Required  Operational  Capability  (TROC). 

The  "broad  look"  at  ETRs  provided  by  the  preliminary  analysis  also 
allows  some  early  ET-related  input  to  the  system  design  process.  ET  is 
typically  implemented  by  integral  or  strap-on  computer  capabilities  of 
the  prime  item  system.  If  there  are  many  ETRs,  and  something  is  known 
about  the  requirements  to  implement  the  ETRs,  then  provisions  can  be 
made  to  include  the  appropriate  computer  processing  and  memory  capabil¬ 
ities  in  the  system  to  implement  ET.  Otherwise,  the  needed  capabili¬ 
ties  could  be  overlooked.  This  could  mean  that  an  effective  ET  compo¬ 
nent  would  be  impossible  or  have  undesired  schedule  or  cost  impacts. 


Iteration  Two:  Early  System  Development 

Once  the  new  system  is  in  the  design  stage  (late  Concept 
Exploration  or  early  Demonstration  and  Validation  for  the  LCSMM;  Proof 
of  Principle  for  the  ASAP),  more  information  is  known  about  human 
performance  requirements  for  the  system.  At  this  point,  the  ETR 
process  needs  to  take  place  once  again,  to  support  identification  of 
ETRs  at  the  behavioral  objective  level.  At  this  level,  the  ETRs  can  be 
used  as  input  to  the  development  of  a  preliminary  ET  component  design 
for  the  system.  In  some  cases,  the  second-iteration  ETRs  will  not  be 
sufficiently  detailed  (because  of  system  maturity  factors)  to  support 
the  ET  component  design.  In  such  cases,  additional  iterations  may  be 
required  at  successive  stages  of  system  development. 


Later  Iterations 


Depending  on  the  rate  at  which  the  system  design  becomes  firm, 
additional  iterations  of  ETR  specification  may  be  necessary.  This  is 
true  particularly  if  major  changes  in  the  functional  allocation  between 
system  and  soldier  performance  requirements  have  taken  place,  or  if 
there  are  significant  design  changes  to  the  soldier-system  interface 
(SSI),  as  a  result  of  technical  or  user  testing. 

The  need  for  additional  iterations  of  the  ETR  identification 
procedures  is  most  likely  when  the  LCSMM  is  used  to  manage  system 
development,  since  there  is  one  more  major  phase  involved  in  system 
acquisition  than  with  the  ASAP.  Additional  iterations  of  the  ETR 
procedures  may  be  needed  during  the  full-scale  engineering  development 
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(FSED)  phase  of  the  LCSMM.  Systems  managed  under  the  ASAP  may  also 
require  additional  iterations  of  the  ETR  procedures  during  the  Develop¬ 
ment  and  Production  Proveout  stage,  as  the  system  matures. 


Overview  of  the  ETR  Identification  Process 


The  remaining  four  section-  of  this  report  present  the  detailed 
procedures  and  guidelines  for  identifying  ETRs .  The  procedures  are 
divided  into  four  pluses,  each  with  several  component  steps.  An 
overview  of  the  phases  of  the  process  is  shown  graphically  in  Figure  1. 
The  procedures  in  Phases  One  and  Two  are  essentially  identical  to  other 
training  front-end  analysis  procedures.  In  fact,  ETR  identification 
may  take  place  as  a  part  of  efforts  to  identify  training  requirements 
for  a  system  overall,  and  to  specify  other  training  media  and 
approaches.  Where  possible,  duplication  of  effort  should  be  avoided, 
and  common  databases  and  resources  should  be  used  for  all 
training-related  front-end  analyses.  These  procedures  allow  ETRs  to  be 
identified  independent  of  other  training  analyses,  to  suit  cases  where 
non- training-oriented  people  must  identify  ETRs,  or  where  ETRs  are 
defined  independent  of  other  analyses  in  support  of  total  training 
system  definition. 

Phase  One  (discussed  in  Section  2)  is  concerned  with  identifying 
the  higher-level  components  (tasks)  of  personnel  performance  which  may 
be  supported  by  an  ET  component.  The  procedures  for  Phase  One  provide 
the  first  part  of  a  complete-in-itself  process  for  ETR  identification 
without  the  need  to  refer  to  other  documents. 

Phase  Two  (described  in  Section  3)  presents  procedures  for 
conducting  task  analysis  to  identify  the  behavioral  performance  objec¬ 
tives  which  are  components  of  the  tasks  identified  in  Phase  One.  These 
procedures  are  exactly  analogous  to  other  task  analysis  procedures,  and 
are  presented  here  for  completeness.  Since  preliminary  identification 
of  ETRs  in  early  stages  of  the  system  life  cycle  may  be  required,  this 
Phase  of  the  process  is  shown  as  optional.  This  is  solely  due  to  the 
fact  that  complete,  valid  data  on  which  to  base  a  detailed  task 
analysis  may  not  be  available  early  in  the  life  cycle,  even  if  HAREMAN 
or  other  ECA  analyses  are  performed.  If  Phase  Two  is  initially 
skipped,  a  detailed  definition  of  the  ETRs,  based  on  a  comprehensive 
task  analysis,  must  be  performed  as  early  as  possible,  later  in  the 
system  life  cycle,  when  data  become  available. 

Phase  Three  (discussed  in  Section  4)  is  specific  to  ETR  decisions. 
Procedures  in  this  Phase  are  concerned  with  nominating  objectives  as 
ETRs,  based  on  perishability  and  criticality  criteria.  (Note:  When 
"objectives"  are  referred  to  in  Phase  Three,  and  following,  this  refers 
to  the  maximum  level  of  detail  achieved  in  previous  phases.  For 
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Figure  1.  Overview  of  Che  Embedded  Training  Requirement  (ETR) 
development  procedures. 


example,  if  Phase  Two  is  not  performed,  "objectives"  refers  to  task- 
level  data.  If  Phase  Two  _i_s_  performed,  "objectives"  refers  to 
behavioral  performance  objectives  or  task  components  identified  in 
Phase  Two.)  These  procedures  also  assess  the  implementation  potential 
of  the  nominated  ETRs  and  identify  possible  approaches  to  implementa¬ 
tion.  Note  that  these  analyses  may  be  performed  along  with  other 
training  system  analyses  with  similar  purposes.  These  analyses  should 
be  conducted  in  parallel  with,  or  integrated  with,  total  training 
system  media  determination  procedures,  where  possible.  Combining  the 
analyses  will  yield  opportunities  to  examine  overall  training  system 
alternatives  and  perhaps  optimize  the  design  of  the  complete  training 
system. 

Phase  Four  (detailed  in  Section  5)  deals  with  presenting  the  iden¬ 
tified  ETRs.  In  practice,  the  database  resulting  from  the  analysis 
phases  tends  to  become  quite  large.  During  ETR  analyses,  many  data 
elements  become  associated  with  each  task  or  behavioral  performance 
objective.  In  Phase  Four,  specific  reports  are  selected  and  prepared 
which  emphasize  various  useful  facets  of  the  data,  and  which  can  be 
used  for  different  purposes  later  in  the  development  of  an  ET  compo¬ 
nent  . 


The  Appendixes 

In  addition  to  the  four  sections  that  present  the  procedures, 
three  Appendixes  are  included  to  support  the  ETR  identification 
process.  Appendix  A  provides  a  generic  mission  phases  model  which  is 
useful  in  Phase  One,  where  system  missions  are  decomposed  into  phases 
as  part  of  the  task  identification  process.  Use  of  this  model,  adapted 
to  the  situation  surrounding  a  particular  system,  is  encouraged,  to 
provide  consistency.  Appendix  B  presents  an  extensive  listing  and 
definition  of  action  verbs  for  use  in  writing  task  and  objective 
statements  in  the  analysis  process.  This  verb  list  is  included  to 
provide  a  standard  reference  for  analysts. 

Appendix  C  presents  information  concerning  the  application  of 
computer  database  management  systems  (DBMSs)  to  support  the  ETR 
analyses,  and  documenting  the  results  of  the  analyses.  In  practice,  it 
has  been  found  that  the  use  of  a  DBMS  on  personal  computers  is  a 
genuine  resource-saver  in  conducting  the  ETR  analyses  and  developing 
reports  and  documentation.  In  Appendix  C,  a  suggested  structure  for 
DBMS  records  is  provided.  This  data  structure  has  been  found  to 
accommodate  the  ETR  analyses  and  documentation  effectively.  Interim 
manual  and  computer-generated  recording  forms  and  formats  are  also 
presented,  and  their  application  in  the  steps  of  the  ETR  analyses  is 
identified.  Some  suggestions  on  the  use  of  DBMS  capabilities  in 
various  parts  of  the  ETR  analyses  are  also  provided  in  this  Appendix. 
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SECTION  2 


PROCEDURES  FOR  PHASE  ONE:  TASK  CHARACTERIZATION 


In  order  to  develop  valid  ETRs ,  the  first  step  is  to  completely 
define  the  activities,  or  tasks,  that  system  personnel  perform  on  the 
job.  The  tasks  will  be  analyzed  in  m  re  detail  and  considered  for  ET 
in  later  phases  of  the  ETR  development  process. 

The  steps  to  be  performed  in  Phase  One,  and  the  products  that  are 
produced,  are  summarized  in  Figure  2. 

The  results  of  the  activities  may  be  entered  into  a  computer  data¬ 
base  for  ease  of  management.  It  is  strongly  suggested  that  a  computer 
DBMS  be  used  to  record  and  structure  analysis  results  and  data,  if  a 
DBMS  is  available  and  if  you  are  familiar  with  its  use.  Using  the 
computer  database  will  also  make  many  of  the  activities  in  later  steps 
and  phases  easier,  because  of  the  flexible  ways  that  appropriate  DBMS 
software  can  manipulate  and  retrieve  data.  A  suggested  structure  for  a 
computer  database  for  ETR  analyses  is  given  in  Appendix  C  of  this 
document.  Good  results  have  been  had  in  ETR  data  management  using 
personal  computers  with  hard  disks  and  several  types  of  data  management 
software.  Any  computer  with  hard-disk  storage,  and  any  data  management 
software  available,  can  be  used.  The  goal  is  to  provide  consistent 
data  management  and  to  ease  the  burden  of  recordkeeping  and  data 
retrieval  imposed  by  the  large  number  of  steps  required  to  specify 
ETRs . 


If  computer  database  capabilities  are  not  available,  or  if 
significant  resources  would  be  required  to  be  able  to  use  a  computer 
database,  manual  recordkeeping  is  perfectly  acceptable.  If  manual 
recordkeeping  is  done,  it  is  recommended  that  the  report  formats  in 
Appendix  C  be  used  as  data  forms. 

The  subsections  that  follow  describe  each  of  the  steps  in  Phase 
One.  Each  subsection  presents  the  objective  of  the  step,  provides 
rationale  for  the  activities  in  the  step,  describes  how  to  perform  the 
step,  and  specifies  the  products  that  should  result  and  how  they  should 
be  recorded  and  documented.  The  steps  should  be  performed  in  the  order 
they  are  listed,  since  the  activities  in  each  step  make  use  of  products 
from  previous  steps. 
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Step  1.1:  Gather  Documentation  on  System  and  Identify  ~ s 
and  Other  Data  Sources 


Objectives :  1.  Identify  available  information  sources  (people  and 
organizations)  about  the  system  for  which  ETRs  are 
being  developed. 

2.  Develop  a  library  of  reference  material  (documentation 
on  the  system  and  the  activities  performed  by  people 
who  operate  the  system)  to  support  analysis. 

3.  Identify  subject  matter  expert  (SME)  resources  to 
provide  additional  information  about  the  tasks  that 
people  perform  and  the  important  characteristics  of 
those  tasks. 

Rationale :  The  analyses  to  define  ETRs  depend  completely  on  accurate, 
comprehensive,  detailed  information  about  what  people  are 
required  to  do  to  make  the  target  system  perform  effec¬ 
tively.  This  information  provides  the  basis  for  developing 
training  objectives  and  training  content.  It  also  assists 
in  deciding  which  aspects  of  job  performance  should  be 
supported  by  ET.  Both  documentation  resources  and  people 
resources  (SMEs)  are  normally  required,  to  provide  the 
information  necessary  for  the  development  of  ETRs  for  a 
system. 

ETRs  may  be  analyzed  either  early  in  the  system  development 
process  or  after  the  system  has  been  fielded.  If  the  ETRs 
are  analyzed  when  a  system  is  in  the  very  early  stages  of 
its  life  cycle,  information  sources  that  are  accurate  and 
romplete  are  likely  to  be  hard  to  come  by.  When  this  is 
the  case,  the  documentation  that  is  available  must  be  used. 
However,  it  does  not  support  a  very  detailed  level  of 
analysis.  Documents  which  describe  the  system,  its 
missions  and  capabilities,  and  the  responsibilities  of 
personnel  at  early  stages  of  the  life  cycle  include  mission 
area  analysis  (MAA)  documentation  (Mission  Area  or 
Battlefield  Development  Plans),  required  operational 
capability  (ROC)  statements,  and  0&0  Plans  for  the  system. 
Other  documentation.  Including  results  of  ECA  or  HAREMAN 
analyses  and  MANPRINT  studies  (including  the  system 
MANPRINT  management  plan  [SMMP] — particularly  the  Target 
Audience  Description),  may  also  be  available.  Some  or  all 
of  these  documents  may  have  been  gathered  to  support 
previous  ET  analyses  (evaluating  ET  as  a  system  alternative 
[Volume  2  of  this  series],  or  identifying  the  role  of  ET  in 
the  training  system  concept  [Volume  3]).  If  so,  such 
documents  can  be  used  to  support  ETR  analyses.  Also, 
products  from  using  the  procedures  in  Volumes  2  and  3  of 
this  series  may  be  of  help  in  getting  started. 

If  necessary,  documentation  about  other  systems  that  have 
similar  missions  or  are  similar  to  the  target  system  (in 
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design  or  technology)  may  be  used.  If  this  is  done, 
however,  a  later  update  of  the  ETR  analysis  (using 
accurate,  complete  information  on  the  actual  target  system) 
will  be  necessary. 

In  some  cases,  the  addition  of  ET  to  a  fielded  system  may 
be  considered.  If  the  ETR  analysis  is  performed  after  the 
system  has  already  been  fielded,  large  amounts  of  documen¬ 
tation  on  the  system  and  the  tasks  and  responsibilities  of 
its  personnel  are  typically  available.  These  information 
sources  are  generally  complete  and  accurate,  especially  if 
the  results  of  other  training  analyses  on  the  system  can  be 
obtained.  Documents  that  are  useful  at  this  stage  include 
technical  manuals  (TMs)  dealing  with  the  target  system, 
field  manuals  (FMs)  describing  how  the  system  is  operated 
and  employed,  and  soldier's  manuals  (SMs)  that  describe  the 
responsibilities  and  tasks  of  the  crewmembers  or  system 
operators  of  the  target  system.  Task  analysis  (for 
example,  Logistic  Support  Analysis  Records  [LSAR] )  and 
training  Front-End  Analysis  information  is  also  useful,  as 
are  the  results  of  any  ISD  analyses  that  have  been  done  on 
the  target  system. 

SMEs  provide  two  critical  services  in  an  ETR  analysis. 
First,  they  can  validate  or  revise  questionable 
information,  and  add  details  that  may  not  be  present  in 
documentation.  This  is  especially  important  in  the  case 
where  information  is  sparse  or  incomplete.  Second,  SME 
input  is  required  to  make  judgments  on  how  critical 
specific  aspects  of  job  performance  are  to  mission 
accomplishment,  when  identifying  tasks  or  performance 
objectives  to  be  included  in  the  ETRs. 

Procedure :  The  first  activity  in  this  step  is  to  identify  agencies 
capable  of  providing  the  necessary  documentation  and  the 
personnel  who  can  serve  as  SMEs.  While  details  will  differ 
from  system  to  system,  sources  include  Project  Manager’s 
staff,  Special  Study  Group  (SSG)  staff  and  reports,  Special 
Task  Force  (STF)  staff  and  reports,  Army  Materiel  Command 
(AMC)  personnel  associated  with  the  system.  Training  and 
Doctrine  Command  (TRADOC'  Training  System  Managers  (TSMs), 
personnel  in  the  Directorates  of  Training  and  Doctrine 
(DOTD)  and  Combat  Development  (DCD)  at  the  proponent  school 
for  the  system,  and  personnel  associated  with  the  system  at 
various  laboratories  and  commodity  commands  (e.g.,  Army 
Missile  Command,  etc.). 

After  sources  have  been  identified,  they  should  be 
contacted,  and  the  documentation  available  from  each  source 
should  be  requested.  In  most  cases,  it  is  recommended  that 
all  available  documentation  be  identified  and  obtained.  If 
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more  information  than  is  useful  is  obtained  at  this  point, 
it  is  better  than  if  insufficient  information  is  available 
later. 

Once  documentation  has  been  received,  it  should  be 
catalogued,  and  a  project  library  should  be  established  for 
ease  of  reference.  If  the  volume  of  documentation  is 
large,  it  may  be  helpful  to  develop  a  computer  database  for 
cataloguing  or  indexing  the  information  sources  for  ease  of 
reference  in  later  steps.  This  can  also  be  helpful  when 
developing  an  audit  trail  (i.e.,  where  the  information  used 
in  the  analysis  came  from)  in  the  analysis  database  in 
later  steps,  since  source-identification  data  can  be  easily 
transferred  from  one  database  to  another. 

SMEs  are  frequently  more  difficult  to  come  by  than  is 
documentation.  The  ideal  SMEs  to  support  an  ETR  analysis 
are  relatively  senior  enlisted  personnel  (Skill  Level  3  or 
higher  in  military  occupational  specialty  [MOS])  who  have  a 
minimum  of  one  year's  recent  experience  on  the  target 
system  or  on  very  similar  systems.  It  is  highly  desirable 
to  have  two  or  more  SMEs  available,  especially  at  critical 
points  in  the  effort,  so  that  different  perspectives  on 
decisions  are  available.  Continuous  SME  involvement  is  not 
absolutely  required  over  the  entire  period  of  the  ETR 
analysis,  but  is  desirable,  if  possible.  If  SMEs  cannot  be 
made  available  on  a  continuous  basis,  their  involvement  at 
specific  points  in  the  analysis  process  is  critical.  The 
steps  where  SME  assistance  and  input  are  essential  are 
indicated  later  in  this  document,  as  they  are  described. 

In  any  case,  it  is  highly  desirable  to  have  the  same  SMEs 
involved  over  the  project  period,  in  order  to  minimize  the 
amount  of  re-familiarization  required  and  its  associated 
delays . 

Products:  The  products  of  this  step  are  the  project  library,  the 

lists  of  personnel  or  offices  in  various  agencies  which  may 
be  contacted  for  additional  information,  and  the 
identification  and  assignment  of  specific  SME  personnel  to 
support  the  project. 
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Step  1.2:  Identify  System  Job  Positions  and  List 


Objective : 


Rationale: 


Procedure : 


Product : 


Identify  each  job  position  involved  in  operation  of  the 
target  system,  including  (if  possible)  MOS,  grade,  and 
other  specific  descriptors. 

The  first  two  phases  of  the  ETR  analysis  are  a  top-down 
analysis  of  the  responsibilities,  tasks,  and  performance  of 
personnel  who  operate  the  system.  It  is  necessary  to  be 
able  to  identify  which  people  do  what  on  the  system,  and 
under  what  circumstances,  in  order  to  identify  valid  ETRs. 
Also,  when  an  ET  component  is  developed  for  the  system,  it 
is  necessary  to  identify  which  personnel  will  interact  with 
the  ET  component,  and  in  what  ways. 

Examine  the  available  documentation  and  determine  the 
titles  of  job  positions  involved  in  system  operation.  Job 
position  titles  should  be  descriptive  of  the  general  duties 
performed  by  each  person  involved  in  system  operation.  For 
example,  an  M109  howitzer  crew  is  normally  composed  of  five 
persons:  a  Chief  of  Section,  a  Gunner,  an  Assistant 

Gunner,  a  Driver/Cannoneer,  and  a  Cannoneer. 

After  the  job  position  titles  have  been  identified  and 
listed,  additional  descriptive  information  about  each 
position  should  be  determined.  As  a  minimum,  the  MOS  and 
grade  for  each  position  should  be  identified.  Other 
information,  such  as  special  qualifications  and 
prerequisites  for  each  position,  should  be  listed  if  it  is 
conveniently  available. 

The  job  position  listing.  Later,  this  listing  will  be  used 
to  identify  which  positions  are  involved  in  performing 
tasks  and  task-component  activities  on  the  system. 
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Step  1.3:  Identify  and  List  All  System  Missions 


The  use  of  Form  1  (see  Appendix  C)  for  interim  data  recording  is 
suggested  for  this  step 
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Step  1.3:  Identify  and  List  All  System  Missions 


Objective :  Identify  and  list  all  of  the  named  missions  (or  functional 

areas)  which  are  to  be  performed  by  the  target  system. 

Rationale :  Since  the  identification  of  tasks  and  personnel  responsi¬ 
bilities  is  a  top-down  process,  a  point  of  departure  is 
needed.  Since  most  systems  are  designed  to  fulfill 
specific  missions  (or  have  analogous  distributions  of 
functions),  beginning  the  analysis  at  the  mission  or 
functional-area  level  provides  a  consistent  starting  place 
for  the  ETR  analysis.  Also,  reviewing  the  missions  (or 
functional  areas)  provides  a  relatively  complete  picture  of 
how  a  system  is  to  be  used.  This  helps  to  make  the 
analyses  complete  by  providing  for  the  various  unique  uses 
of  the  system. 

Procedure :  Using  documentation  and  SMEs  (if  available),  list  each 

mission  performed  by  the  target  system.  An  excellent 
resource  for  mission  listings  data  is  the  0&0  concept  for 
the  system.  This  document  normally  lists  all  missions  and 
mission  variants  contemplated  for  the  system.  An 
additional  advantage  of  the  0&0  concept  as  a  resource  is 
that  it  is  normally  prepared  very  early  in  the  system  life 
cycle.  More  stable  data  for  systems  which  are  in  later 
part.:  of  the  life  cycle  are  typically  found  in  FMs,  SQTs , 
TMs,  and  ARTEPs. 

When  considering  missions,  guidelines  useful  for 
discriminating  missions  are  the  following:  (1)  a  mission 
is  a  related  set  of  activities  normally  performed  by  a  crew 
or  other  system  of  individuals,  (2)  a  mission  has  clearly 
definable  beginning  and  ending  points,  and  (3)  missions  are 
often  related  to  specific  end  goals  of  coordinated  crew 
activities . 

It  should  be  recognized  that  not  all  systems  will  have  more 
than  one  mission.  For  example,  tanks  may  have  many 
missions,  but  an  anti-tank  weapon  may  have  only  one.  Tanks 
can  have  both  direct  and  indirect  fire  missions,  and  can  be 
employed  in  counter-armor,  counter-asset,  offensive,  and 
defensive  roles.  These  could  all  be  considered  distinct 
missions.  On  the  other  hand,  anti-tank  weapons  are  used  to 
kill  tanks,  and  for  very  little  else,  except  in  very 
unusual  circumstances.  In  general,  the  more  flexible  the 
overall  capabilities  of  a  given  system,  the  more  missions 
it  may  have,  other  factors  being  equal. 

In  some  cases,  systems  do  not  have  named  missions .  Rather, 
there  may  be  some  other  breakdown  of  functional 
requirements  for  a  system.  For  example,  some  command, 
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Product : 


control,  communications,  and  intelligence  (C3I)  systems 
support  various  functions  (intelligence  gathering,  database 
management,  intelligence  analysis,  electronic  mail,  etc.) 
that  are  analogous  to  the  missions  performed  by  weapon 
systems.  If  this  is  the  case,  some  appropriate  functional 
breakdown  should  be  identified  and  used  in  the  ETR 
analysis . 

The  listing  of  unique  missions  (or  analogous  functional 
areas)  for  the  system. 

NOTE:  In  the  rest  of  this  document,  the  term  "mission" 

refers  to  both  missions  and  to  other  functional  breakdowns 
that  may  be  used. 
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Step  1.4:  Establish  Computer  or  Manual  Database  -  Enter  Missions  Data 
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The  use  of  Form  1  (see  Appendix  C)  for  interim  data  recording  is 
suggested  for  this  step 
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Step  1.4:  Establish  Computer  or  Manual  Database  - 
Enter  Missions  Data 


Objective :  Develop  and  implement  a  complete  and  comprehensive  database 

to  support  documentation  and  analysis  in  subsequent  steps 
of  the  ETR  identification  process. 

Rationale :  Using  a  computer  database  management  system  to  support  the 

ETR  analyses  saves  time  in  the  documentation  of  most  steps, 
and  makes  the  retrieval,  modification,  and  analysis  of  data 
much  easier.  Database  management  software  also  facilitates 
preparation  of  reports  for  the  intermediate  and  final  steps 
of  the  ETR  development  process,  and  provides  for  a  consis¬ 
tent  and  comprehensive  level  of  detail  in  the  data.  If  it 
is  not  feasible  to  use  a  computer  database,  then  use 
Appendix  C  to  set  up  a  manually  managed  paper  database. 

The  suggested  forms  in  Appendix  C  can  be  reproduced  to 
support  a  manual  system. 

Procedure :  Using  available  database  management  software  (or  a  manual 

system),  establish  a  data  structure  similar  to  that 
presented  in  Appendix  C  of  this  report.  All  of  the  data 
fields  described  in  Appendix  C  should  be  defined  in  the 
data  structure  that  is  implemented. 

After  the  data  is  implemented,  enter  the  discrete  missions 
(or  functional  areas)  identified  in  Step  1.3  as  individual 
records  in  the  database,  with  appropriate  codes  and 
descriptions.  If  only  one  mission  was  identified  in  Step 
1.3,  there  is  no  need  to  enter  mission  records.  Also, 
enter  the  data  sources  that  were  used  to  identify  each 
mission. 


Products :  The  implemented  data  structure  and  mission  descriptor 

records  (it  applicable). 
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Step  1.5: 


Identify  and  List  Mission  Phases  for  Each  Mission;  Add 
Mission  Data  to  Database 
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interim  data  recording  is 
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Step  1.5:  Identify  and  List  Mission  Phases  for  Each  Mission;  Add 
Mission  Data  to  Database 


Objective:  Identify  all  discrete  mission  phases  for  each  system 

mission  and  add  the  mission  phase  data  to  the  database. 

Rationale :  Decomposing  missions  into  phases  is  the  next  step  in  the 

top-down  analysis  to  develop  the  complete  database  for 
identifying  ETRs. 

Procedure :  For  each  of  the  missions  identified  in  Step  1.3,  use 

documentation  and  SME  resources  to  identify  the  phases  of 
the  missions.  Mission  phases  have  the  following  character¬ 
istics:  (1)  each  mission  phase  can  be  given  a  meaningful 

name,  (2)  each  mission  phase  has  a  logical  beginning  and 
ending  point,  (3)  each  mission  phase  occupies  a  unique  time 
slice  within  the  mission,  and  (4)  all  phases  taken  together 
describe  an  entire  mission. 

Good  sources  for  mission  phase  description  data  are  SMs, 

TMs  for  the  system  or  for  very  similar  systems  (if  avail¬ 
able),  SMEs,  and  other  persons  (e.g.,  combat  developers, 
other  departments  of  the  contractor  organization)  working 
on  the  problem  for  other  reasons.  When  SMEs  are  used  to 
identify  mission  phases,  they  should  be  briefed  on  the  four 
characteristics  listed  in  the  previous  paragraph,  and 
provided  documentation  for  reference.  If  desired,  the 
generic  mission  phases  model  presented  in  Appendix  A  can  be 
used  as  a  starting  point  for  mission  phase  identification. 
It  will  probably  be  necessary  to  adapt  this  generic  model 
to  the  specific  system  that  is  being  considered.  Also  note 
that  the  generic  mission  phases  model  is  based  on  typical 
ground  weapon  system  missions.  Aircraft  systems  and 
non-weapons  systems  may  have  very  different  mission  phase 
breakdowns.  Some  non-weapons  systems  may  not  have  mission 
phase  structure  at  all.  However,  such  systems  usually  have 
functional  groupings  of  tasks  that  are  analogous  to  mission 
phases.  Such  task  groupings  can  be  used  to  organize  the 
remainder  of  the  analysis  process,  instead  of  mission 
phases  . 

As  mission  phases  (or  other  functional  groupings)  for  each 
mission  are  identified,  they  should  be  listed,  by  mission. 
Also,  the  documents  or  other  sources  used  to  derive  the 
mission  phases  should  be  recorded,  to  provide  an  audit 
trail  for  the  analyses.  After  identifying  phases  for  all 
missions,  enter  the  mission  phases  for  each  mission  as 
records  in  the  database.  Codes  used  for  the  mission-phase 
records  should  be  one  level  subordinate  to  the  codes  used 
for  mission  records.  Also,  the  codes  assigned  to  phases  of 
each  mission  should  reflect  the  sequence  of  the  phases  in 
the  mission. 

Product  :  Mission  phase  listings  for  each  mission,  entered  as  mission 

phase  records  in  the  computer  database. 
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Step  1.6:  Perform  Mission  Phases  Commonality  Analysis  and  Annotate 
Database 


The  generation  and  use  of  Form  2  (see  Appendix  C)  for  interim  data 
recording  is  suggested  for  this  step 
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Step  1.6:  Perform  Mission  Phases  Commonality  Analysis 
and  Annotate  Database 


Objective: 


Rationale : 


Procedure : 


Identify  and  annotate  the  unique  mission  phases  among  the 
various  missions.  (NOTE:  This  step  may  be  omitted  when 
there  is  only  one  mission  or  functional  task  area  defined 
for  a  systoro. ) 

Later  steps  in  the  analysis  process  may  consume  large 
amounts  of  time  and  resources.  If  several  missions  have 
identical  ohases,  it  makes  no  sense  to  duplicate  effort  in 
analyzing  the  tasks  and  operator  behaviors  contained  in 
such  phases  more  than  once.  This  step  identifies  the 
phases  that  are  unique  among  all  the  missions  identified. 
Only  the  unique  mission  phases  will  be  considered  in  later 
steps. 

Obtain  a  listing  of  mission  phases  (sorted  or  indexed  by 
mission)  from  the  database.  Use  this  listing  to  identify 
the  phases  in  different  missions  that  have  similar  or 
identical  titles.  Using  SMEs  as  a  primary  source,  review 
all  of  the  mission  phases  that  have  similar  or  identical 
titles  in  different  missions,  and  judge  which  of  these 
phases  are  unique.  An  appropriate  approach  is  to  consider 
all  possible  pairs  of  mission  phases  with  similar  titles. 
Questions  to  ask  when  trying  to  determine  if  phases  with 
similar  titles  are,  in  fact,  identical  are: 

1.  Are  there  different  goals  or  objectives  among  mission 
phases  with  similar  titles?  If  yes,  the  phases  may  be 
unique . 

2.  Is  the  system  or  its  subsystems  used  in  different  ways 
in  mission  phases  with  similar  titles?  If  yes,  the 
phases  are  probably  unique. 

3.  Are  there  differences  in  the  responsibilities  allocated 
among  operators  or  crewmembers  across  phases  with 
similar  titles?  If  yes,  it  is  likely  that  the  phases 
are  unique. 

As  the  phases  are  evaluated,  identify  the  first  occurrence 
of  identical  phases.  Then  identify  each  phase  that  is 
identical  to  these  first  ones.  Generally,  the  "first 
occurrence"  phases  should  be  those  with  lower  numbered 
mission  codes  in  the  database. 

After  all  phases  have  been  evaluated,  annotate  the 
mission-phase  database  records.  Two  kinds  of  annotation 
will  be  needed.  The  first  is  to  identify  the  unique  phases 
and  the  "identical"  phases  that  are  the  same  as  the  unique 
ones.  Using  a  logical  database  field,  code  the  unique 
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Product : 


phases  as  "True"  and  the  "identical"  phases  as  "False." 

The  second  kind  of  annotation  is  a  cross-reference  of  the 
phases  that  are  identical.  It  is  suggested  that  the  database 
codes  of  all  "identical"  mission  phases  be  listed  in  the 
appropriate  field  of  the  unique  "first  occurrence"  phase  to 
which  they  are  identical. 

Database  annotations  indicating  unique  and  "identical" 
mission  phuses,  and  cross-reference  fields  in  the  unique 
mission-phase  records. 


23 


Seep  1.7:  Identify  Tasks  and  Conditions  for  Each  Unique  Mission 
Phase;  Add  Task  Data  to  Database 
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The  use  of  Form  1  (see  Appendix  C)  for  interim  data  recording  is 
suggested  for  this  step 
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Ste 


Objective : 


Rationale : 


Procedure : 


1.7:  Identify  Tasks  and  Conditions  for  Each  Unique 

Mission  Phase;  Add  Task  Data  to  Database 


Identify  all  tasks  performed  by  operators  or  crewmembers 
while  performing  each  unique  mission  phase  (or  other 
functional  break-out),  and  the  conditions  under  which  each 
task  is  performed. 

Decomposing  mission  phases  into  tasks  is  the  next  step  in 
the  top-down  analysis  to  develop  the  complete  database  for 
identifying  ETRs. 

The  following  procedures  are  performed  for  each  unique 
mission  phase  or  other  functional  break-out  used.  The 
primary  information  sources  are  documentation  (SMs  and 
ARTEP  documents  are  good  sources)  and  SMEs.  Other  useful 
data  may  come  from  application  of  procedures  in  Volume  2 
(ET  as  a  System  Alternative)  and  Volume  3  (The  Role  of  ET 
in  the  Training  System  Concept)  in  this  series.  If  only 
documentation  is  used  for  initial  identification  of  tasks, 
the  task  listings  should  be  validated  by  two  or  more 
knowledgeable  SMEs  and  should  later  be  updated,  as 
appropriate,  based  on  their  comments. 

1.  Go  through  each  unique  mission  phase  in  sequence, 
identifying  and  listing  all  tasks.  In  identifying 
tasks,  look  for  names  of  products  produced  by  personnel 
while  doing  their  duties,  or  names  of  processes  they 
use  to  accomplish  goals.  Also,  consider  the  following 
characteristics  when  identifying  tasks: 

a.  Tasks  are  significant  operator  activities  that 
can  be  named. 

b.  Each  task  has  an  observable  beginning  and  ending 
point,  or  results  in  a  consistently  identifiable 
product . 

c.  Most  tasks  include  a  consistent  sequence  of 
specific  behaviors  (these  will  be  dealt  with  in 
Phase  Two) . 

Task  names  should  consist  of  an  action  verb,  a  noun 
that  specifies  the  object  of  the  action  verb,  and  an 
appropriate  modifier  (or  qualifier)  phrase  that  briefly 
describes  how  the  action  is  carried  out.  Modifier 
phrases  should  be  neither  too  detailed  (getting  into 
specifics)  nor  too  general.  For  example,  the  task 
statement  for  manual  laying  of  a  howitzer  might  be  "Lay 
howitzer,  using  manual  method,"  A  list  of  generic 
action  verbs  for  use  in  developing  task  statements  is 
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provided  in  Appendix  B.  Note  that  some  special  action 
verbs,  such  as  to  "lay"  a  howitzer,  may  be  absent  from 
this  list,  although  they  are  common  in  traditional 
military  usage.  These  should  be  used  when  necessary 
for  clarity. 

Provide  sufficient  detail  to  enable  the  listing  to  be 
validated  by  someone  else  using  the  same  resources.  If 
enough  detail  is  not  provided,  important  tasks  may  be 
omitted  from  consideration  or  be  analyzed  wrongly  in 
later  steps  of  the  ETR  identification  process. 
Generally,  an  appropriate  level  of  detail  in  listing 
tasks  is  considered  to  be:  (a)  the  point  below  which 
task  components  would  be  described,  rather  than  tasks 
and  (b)  the  lowest  level  at  which  performance  might  be 
evaluated  independently  from  other  contiguous  tasks. 

An  example  of  a  task  statement  that  is  not  sufficiently 
specific  is  "Lay  howitzer,"  since  there  are  several 
methods  for  laying  the  howitzer.  An  example  of  a  task 
statement  that  is  too  specific  is  "Select  the  manual 
alignment  mode  on  the  inertial  navigation  system." 

This  is  a  behavioral  component  of  a  task. 

As  tasks  are  identified,  they  should  be  given  numeric 
codes  that  reflect  their  level  in  the  database 
hierarchy.  Task  codes  are  one  level  below  mission 
phase  (or  other  functional  area)  codes.  For  example,  a 
code  for  the  ninth  task  in  Mission  1,  Phase  6  would  be 
01.06.09.  These  codes  will  reflect  the  position  and 
level  of  subordination  of  the  task  in  the  overall 
operator  performarce  hierarchy. 

2.  After  all  tasks  in  a  mission  phase  have  been  identi¬ 
fied,  organize  the  tasks  so  that  all  the  tasks  at  each 
level  in  the  task  hierarchy  are  independent.  Review 
each  task,  and  ask  the  question,  "Can  this  task  be 
subsumed  under  any  other  task  listed  at  this  level  for 
this  mission  phase?"  If  it  can,  then  the  task  should 
be  moved  to  a  lower  level  in  the  hierarchy.  Task 
statements  at  each  level  in  the  task  hierarchy  should 
be  completely  independent  of  each  other — neither 
subordinate  nor  superordinate. 

3.  Continue  identifying  tasks  in  each  unique  mission  phase 
until  all  of  the  mission  phases  have  been  analyzed. 
After  completing  the  task  identification  for  a  mission 
phase,  add  the  task  data  (task  statements  and  hierarchy 
numeric  codes)  to  the  database  as  separate  task 
records .  Also,  include  the  information sourceTs)  you 
used  to  identify  each  task. 
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4.  Identify  the  conditions  of  performance  for  each  mis¬ 
sion,  phase,  and  task.  Conditions  are  the  "givens"  of 
a  performance.  They  describe  the  circumstances  under 
which  a  task  is  performed.  Conditions  may  include  (but 
are  not  limited  to)  the  following: 

a.  Environmental  factors  (such  as  space,  light, 
noise  or  quiet,  temperature,  wind,  weather,  or 
system  conditions). 

b.  Relationships  to  other  personnel  (alone,  working 
as  part  of  a  team  or  crew,  under  supervision, 
etc  . ) . 

c.  Equipment  factors  (what  job  aids,  tools, 
equipment,  etc.  are  available  or  provided). 

d.  Information  (what  job-relevant  information  is 
available  at  the  workplace;  checklists,  operator 
manual,  charts,  etc.). 

e.  Problem  definition  (what  stimuli  are  present  to 
signal  that  a  task  is  to  be  initiated;  system 
characteristics  that  provide  cues  and  "feel," 
etc  . )  . 

f.  Time  (duration,  pacing,  etc.). 

g.  Concurrent  tasks. 

Add  the  conditions  information  to  each  mission,  unique 
mission  phase,  and  task  record  in  the  database. 

5.  List  all  additional  tasks  required  in  each  mission 
phase  for  performance  under  extraordinary  conditions. 
Extraordinary  conditions  include  malfunctions, 
emergencies,  and  abnormal  systsn  conditions  (such  as 
operating  at  half  power  because  one  of  two  engines  has 
failed).  This  is  best  accomplished  by  asking,  for  each 
mission,  phase,  and  task,  "Are  there  any  conditions 
under  which  this  is  performed  that  require  deviations 
from  normal  procedures?"  Note  that  SME  input  is 
extremely  valuable  at  this  step;  documentation  often 
deals  only  with  normal  system  operation  or  operating 
under  nominal  conditions.  The  existence  of 
extraordinary  conditions  requires  the  identification  of 
tasks  previously  overlooked  in  developing  the  task 
listings.  New  tasks  created  by  identifying 
extraordinary  circumstances  are  added  to  the  task 
database  and  are  subsequently  treated  the  same  as  any 
other  task. 
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Product : 


6.  Re-examine  and  validate  the  task  listing.  Review  the 
task  listing  against  the  available  documentation,  and 
with  one  or  more  SMEs  who  were  not  involved  in  the 
original  development  of  the  task  listing  (if  possible), 
to  identify  possible  omissions  and  errors.  Add  to  the 
database  any  tasks  that  were  overlooked,  and  correct 
any  errors  that  were  discovered  during  the  validation 
process . 

The  validated  task  data,  added  to  the  project  database. 
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Step  1.8: 


Perform  Task  Commonality  Analysis  and  Annotate 
Database  and  Cross-Reference 
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Step  1.8:  Perform  Task  Commonality  Analysis  and 
Annotate  Database  and  Cross-Reference 


Objective : 

Rationale : 


Procedure : 


Identify  and  annotate  the  unique  tasks  among  the  various 
mission  phases  (or  other  functional  break-outs). 

Later  steps  in  the  analysis  process  may  consume  large 
amounts  of  time  and  resources.  If  there  are  identical 
tasks  in  several  mission  phases,  it  makes  no  sense  to 
duplicate  effort  by  analyzing  these  tasks  (to  identify 
their  operator  behaviors)  more  than  once.  This  step 
identifies  the  tasks  that  are  unique  among  all  the  tasks 
identified.  Only  the  unique  tasks  will  be  considered  in 
later  steps. 

Obtain  from  the  database  a  listing  of  tasks  sorted  or 
indexed  by  task  statement.  Use  this  listing  to  identify 
those  tasks  (in  the  same  or  different  mission  phases)  that 
have  similar  or  identical  task  statements.  Using  two  or 
more  SMEs  as  primary  sources,  review  all  of  the  tasks 
having  similar  or  identical  statements,  and  judge  which  of 
the  tasks  are  unique.  An  appropriate  approach  is  to 
consider  all  possible  pairs  of  tasks  with  similar  or 
identical  titles.  Questions  to  ask  when  trying  to 
determine  whether  tasks  with  similar  statements  are,  in 
fact,  identical  are: 

1.  Are  there  different  goals  or  objectives  among  tasks 
with  similar  titles?  If  yes,  the  tasks  may  be  unique. 

2.  Is  the  system  or  its  subsystems  used  in  different  ways 
in  tasks  with  similar  statements?  If  yes,  the  tasks 
probably  are  unique. 

3.  Are  there  differences  in  the  responsibilities  allocated 
among  operators  or  crewmembers  across  tasks  with 
similar  statements?  If  yes,  it  is  likely  that  the 
tasks  are  unique. 

As  the  tasks  are  evaluated,  identify  those  tasks  that  are 
the  first  occurrences  of  identical  tasks.  Also,  identify 
each  task  that  is  identical  to  these  "first  occurrence" 
tasks.  Generally,  the  "first  occurrence"  tasks  should  be 
those  with  lower  numbered  codes  in  the  database. 

After  all  tasks  have  been  evaluated  az  described  above, 
annotate  the  task  database  records.  Two  kinds  of 
annotation  will  be  needed.  The  first  is  to  identify  the 
unique  tasks  and  the  "identical"  tasks  that  are  the  same  as 
the  unique  ones.  Using  a  logical  database  field,  code  the 
unique  tasks  as  "True"  and  the  "identical"  tasks  as 


30 


Product : 


"False."  The  second  kind  of  annotation  is  a  cross- 
reference  of  the  tasks  that  are  identical.  It  is  suggested 
that  the  database  codes  of  all  "identical"  tasks  be  listed 
in  the  appropriate  field  of  the  unique  "first  occurrence" 
tasks  to  which  they  are  identical. 

Database  annotations  indicating  unique  and  "identical" 
tasks,  and  cross-reference  codes  placed  in  the  unique  task 
records. 
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Associated  With  Each  Task  and 


Step  1.9:  Identify  Job  Positions  Associated  With  Each  Task 
and  Annotated  Database 


Objective : 

Rationale : 


Procedure : 


Product : 


Identify  the  personnel  involved  in  performing  each  system 
operation  task. 

Knowing  which  operators  or  crewmembers  are  involved  in 
performing  each  system  task  is  critical  to  later  design  of 
an  effective  ET  component  for  the  system.  Identifying  the 
personnel  involved,  at  this  point  in  the  analysis,  also 
provides  data  for  later  use  in  judging  whether  particular 
activities  are  appropriate  for  inclusion  in  an  ET 
component . 

Develop  unique  one-letter  codes  for  each  system  operator  or 
crewmember  position  (e.g.,  C  for  chief-of-section,  L  for 
loader,  D  for  driver,  etc.).  Obtain  a  listing  of  all  the 
unique  tasks  identified  in  Step  1.8.  Using  documentation 
and  SMEs  (if  needed),  examine  each  task  statement,  and 
identify  the  system  operator  or  crew  personnel  involved  in 
performing  each  task.  List  the  appropriate  codes  to 
reflect  the  crewmembers  involved  in  each  task.  Add  these 
codes  to  the  unique  task  database  records. 

Note:  If  the  procedures  in  Volume  3  of  this  series  (The 

Role  of  ET  in  the  Training  System  Concept)  have  been 
performed,  job  positions  by  functional  area  information 
will  have  been  generated.  Use  this  information  to  help  in 
this  step,  if  it  is  available. 

Annotations  to  unique  task  database  records  reflecting 
which  personnel  are  involved  in  performing  each  unique 
task . 
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SECTION  3 


pkOCEu'JRES  FOR  PHASE  TWO:  PERFORM  DETAILED  TASK  ANALYSIS 


Normally,  the  procedures  presented  "'n  Phase  Two  are  not  segregated 
from  Phase  One  procedures.  In  most  ISD  analyses,  these  activities  are 
performed  in  sequence.  In  considering  ETRs,  however,  there  are  two 
possible  cases.  The  first  is  the  normal  case  where  ET  analyses  and 
other  analyses  to  define  training  system  characteristics  are  carried 
out  together.  In  this  situation,  task  analysis  will  always  be  done, 
immediately  following  validation  of  the  task  listings. 

The  second  case  is  when  it  is  necessary  to  define  preliminary  ETRs 
early  in  the  system  life  cycle — before  specific  data  on  the  system 
being  assessed  are  available.  ET  commonly  interacts  to  a  certain 
extent  with  prime  item  system  design  characteristics.  This  means  that 
an  analysis  may  be  necessary  to  evaluate  the  extent  that  the  system 
will  have  to  be  designed  with  hardware  and  software  features  unique  to 
the  ET  capability.  Also,  early  analyses  in  support  of  ET  and  other 
training  system  development  may  provide  insights  into  effective  design 
of  the  soldier-machine  interface,  since  task  data  and  the  relationships 
of  tasks  and  soldier  functions  are  considered.  The  front-end  analysis 
procedures  for  identifying  ETRs  have  been  divided  into  two  separate 
Phases  to  accommodate  this  second  case. 

If  the  analysis  is  being  carried  out  under  the  second  case,  Phase 
Two  can  be  skipped  and  preliminary  ETRs  can  be  defined  at  the  task 
level.  If  this  is  done,  a  more  detailed  analysis  (with  task  analysis) 
to  further  define  ETRs  must  be  carried  out  concurrent  with  other 
training  front-end  analyses  later  in  system  development.  It  is 
difficult  to  specify  exact  sources  for  task  data  for  the  task  analysis 
procedures  very  early  in  the  system  acquisition  cycle  (e.g.,  the 
concept  development  stage).  If  system  baselines  have  been  selected  or 
synthesized  as  part  of  ECA  or  HARDMAN,  information  on  operator  tasks 
for  the  baseline  system(s)  used  for  those  analyses  may  be  appropriate. 
Caution  is  suggested  if  such  an  approach  is  used,  however.  HARDMAN 
analyses  concentrate  on  maintenance  implications  of  potential  system 
designs.  The  sold ier-machine  interface  and  task  allocations  between 
soldiers  and  hardware/software  components  of  new  systems  may  differ 
markedly  from  those  of  the  system(s)  used  as  HARDMAN  baselines. 

If  human  factors  engineering  (HFE)  functional  allocations  have 
been  performed  for  the  new  system,  it  may  be  possible  to  construct  an 
operator  baseline  composite  system  based  on  the  functional  allocations, 
and  assumptions  from  existing  systems'  capabilities.  This  sort  of 
composite  can  be  used  for  initial  ET  requirements  and  training  system 
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requirements  determination  analyses.  The  same  caution  as  above  for 
using  data  from  baseline  systems  applies  to  this  case.  Also,  great 
care  must  be  taken  not  to  accept  working  baseline  composites  as  drivers 
of  the  characteristics  of  operator  tasks,  in  later  stages  of  the  system 
acquisition  process.  Later  re-definition  of  the  training  system  and  ET 
requirements  must  be  made  based  on  accurate  data  from  the  target 
system. 

An  overview  of  the  steps  performed  in  Phase  Two  is  provided 
graphically  in  Figure  3.  The  following  subsections  present  the 
procedures  for  task  analysis  and  definition  of  performance  objectives. 
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Figure  3.  Overview  of  Phase  Two  procedures. 
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Step  2.1:  Perform  Task  Analysis;  Add  Behavioral  Performance 
Objectives  to  Database 


The  use  of  Form  1  (see  Appendix  C)  for  interim  data  recording  is 
suggested  for  this  step 
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Step  2.1:  Perform  Task  Analysis;  Add  Behavioral  Performance 
Objectives  to  Database 


Objective :  Analyze  each  unique  operator  task  to  identify  the 

behavioral  performance  objectives  included  in  the  task. 

Rat ionale :  In  order  to  design  effective  task  training,  it  is  necessary 
to  know  exactly  how  personnel  perform  each  task  for  which 
they  are  responsible.  For  developing  ET  or  standalone 
training  devices,  it  is  also  necessary  to  understand 
specifically  how  the  equipment  system  and  the  operator 
interact.  Decisions  about  the  appropriateness  and 
feasibility  of  providing  ET  for  particular  tasks  depend 
partly  on  the  stimuli  provided  by  the  equipment  system  and 
the  environment,  and  partly  on  the  actions  that  personnel 
must  perform  to  respond  to  or  control  those  stimuli.  Thus, 
each  task  must  be  broken  down  into  its  behavioral 
performance  components.  This  analysis  performs  that 
breakdown . 

Procedure :  Using  documentation  and  knowledgeable  SMEs  (if  available), 

perform  the  steps  described  below  for  each  unique  task  in 
the  database. 

1.  Divide  the  task  into  its  component  subtasks.  This  is 
normally  done  by  identifying  each  behavioral  action 
performed  by  the  operator  in  accomplishing  the  task. 
Both  overt,  observable  acts  and  decisions  or  judgments 
should  be  considered  to  be  subtasks  or  elements  of  a 
task.  Each  performance  component  identified  should  be 
listed,  with  a  hierarchial  database  code  that  reflects 
its  position  under  the  task  being  analyzed.  It  is 
suggested  that  the  components  for  each  task  be  entered 
into  the  database  as  analysis  of  that  task  is 
completed.  Source  data  should  also  be  included  in  the 
objective  database  records. 

2.  Determine  whether  all  of  the  necessary  decisions  in 

performing  the  task  have  been  identified  as  performance 
components.  Clues  as  to  when  a  decision  is  required 
include:  (a)  when  personnel  must  decide  when  to 

perform  a  procedure,  (b).when  personnel  must  determine 
which  of  several  alternate  rules  or  procedures  to  use, 
(c)  when  personnel  must  evaluate  the  adequacy  of  a 
procedure  or  a  product,  and  (d)  when  personnel  must 
decide  when  a  procedure  should  be  stopped.  When  a  new 
decision  is  identified  in  this  evaluation,  add  it  to 
the  components  list  for  that  task.  The  description  of 
the  decision  must  spell  out  exactly  what  decisions 
personnel  must  make  to  perform  the  task  in  all 
situations . 
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3.  Determine  whether  memorization  is  a  significant  element 
of  the  task.  This  is  true  if  typical  trained  personnel 
would  be  unable  to  perform  the  task  as  a  whole,  if  they 
could  not  remember  which  task  components  must  be 
performed,  or  the  order  in  which  they  should  be 
performed.  This  is  also  true  if  a  person  must  remember 
large  amounts  of  reference  information  to  use  in  the 
task  (for  example,  communications  codes).  If  job  aids, 
computer  prompts,  or  other  memory  aids  for  performing 
the  task  are  likely  to  be  available,  then  memorization 
should  not  be  identified  as  a  significant  element  of 
the  task.  If  memorization  is  a  significant  component, 
then  memorization  must  be  added  to  the  list  of  compo¬ 
nents  for  a  task.  The  memorization  objective  should  be 
at  the  same  level  of  importance  as  other  task  compo¬ 
nents. 

4.  Determine  if  loo  many  subtasks  or  performance  compo¬ 
nents  have  been  identified.  Do  this  by  examining  the 
components  which  have  been  identified,  collectively. 
There  are  too  many  components  when: 

a.  a  component  is  a  lower-level  element  of  any 
other  component  listed;  or 

b.  any  component  repeats  any  other  component 
listed;  or 

c.  any  component  is  not  necessary  to  accomplishment 
of  the  task;  or 

d.  any  component  is  trivial. 

If  there  are  too  many  components,  perform  Step  5; 
otherwise  skip  Step  5  and  go  to  Step  6. 

5.  Narrow  the  list  of  components  to  the  minimum  required 
to  perform  the  task.  Do  this  in  one  or  more  of  the 
following  ways: 

a.  eliminate  components  that  overlap; 

b.  eliminate  any  component  that  is  part  of  another 
component; 

c.  eliminate  unnecessary  components  (that  are  not 
essential  to  task  performance);  or 

d.  group  trivial  components  into  major  logical 
categories,  and  designate  each  category  as  a 
single  component. 
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6.  Determine  whether  there  are  too  few  components.  If, 

after  having  mastered  all  of  the  performance  components 
listed  under  a  task  at  this  point  in  the  analysis,  a 
person  would  be  unable  to  perform  the  overall  task 
after  receiving  a  few  simple  instructions  and  a  minimal 
amount  of  practice,  then  one  or  more  components  has 
been  omitted.  If  this  is  true,  re-examine  the  task  and 
the  missing  critical  components  to  the  list  of  task 
elements.  Add  components  as  required,  so  that  the 
following  statement  is  true: 


Criterion-Level 
Performance  of 
All  + 

Components 


Some  Minimal 
Instructions 
&  Practice 


Criterion-Level 
Performance  of 
the 

Entire  Task. 


7.  Determine  if  there  are  training-related  components  for 
the  task.  Training-related  components  are  behaviors 
that  must  be  performed  in  the  training  environment 
only ,  as  distinguished  from  mission-oriented  compo¬ 
nents.  This  type  of  component  is  included  to  facili¬ 
tate  the  learning  of  mission-related  components  (for 
example,  touch-and-go  landings  and  stall  recovery 
procedures  in  flight  training;  simulation  of  emergency 
conditions  or  malfunctions;  etc.).  If  a  need  for 
training- related  components  is  found,  add  those 
components  to  the  component  list  for  the  task. 
Training-related  components  stiould  be  identified  by  a 
unique  code  so  that  they  are  distinct  from  mission- 
related  components. 


8.  Identify  conditions  of  performance  for  each  component. 
These  conditions  are  of  the  same  sort  that  were 
developed  for  tasks  in  Phase  One,  Step  1.7.  Use  the 
same  procedures  and  criteria  as  in  Step  1.7  to  identify 
conditions  for  performance  components. 


9.  Ensure  that  the  performance  components  under  the  task 
are  coded  to  reflect  their  hierarchial  relationship  to 
the  task. 


10.  Determine  whether  each  performance  component  is  a 
basic-level  behavior  (not  trivial,  but  a  required 
element  of  performance).  If  all  performance  components 
identified  under  a  task  are  basic-level  behaviors 
(e.g.,  individual  procedural  steps,  specific  decisions, 
or  judgments),  then  analysis  of  that  task  is  complete. 
If  there  are  components  which  are  higher  than 
basic-level  behaviors,  then  analyze  those  components 
in  turn,  until  basic-level  behaviors  have  been 
identified  for  all  aspects  of  task  performance. 
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Product : 


Multiple  levels  of  components  under  a  task  should  be 
assigned  hierarchy  codes  which  reflect  their 
subordination  to  higher-level  components  and 
super ordination  over  lower-level  components. 

11.  Validate  the  performance  objectives  database.  If,  as 
suggested  above,  the  components  of  each  task  are  added 
to  the  database  on  completion  of  the  analysis  of  the 
task,  a  final  review  of  the  database  should  be  made 
before  moving  to  the  next  step.  This  consists  of 
obtaining  an  indexed  listing  of  the  entire  database, 
and  validating  that  all  mission,  phase,  task,  and 
behavioral  performance  objective  data  have  been  entered 
correctly,  and  that  the  numeric  codes  of  all  elements 
of  the  database  accurately  reflect  the  hierarchial 
relationships  among  the  elements. 

Complete  task  analysis  information,  added  to  the  project 

da  t  a  ba  s  e . 
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Step  2.2:  Identify  Performance  Standards  Dimensions  and  Add 
Standards  Information  to  Database 


The  generation  and  use  of  Form  4  (see  Appendix  C)  for  interim  data 
recording  is  suggested  for  this  step 
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Step  2.2:  Identify  Performance  Standards  Dimensions 
and  Add  Standards  Information  to  Database 


Ob j ect ive : 

Rationale : 


Procedure : 


Product : 


Identify  the  dimensions  on  which  performance  of  each 
performance  objective  will  be  assessed. 

One  of  the  major  distinguishing  advantages  that  ET  affords 
is  its  superior  ability  to  measure  and  assess  trainee 
performance.  To  be  sure  that  appropriate  performance 
measurement  is  provided  by  an  ET  component,  the  dimensions 
of  correct  performance  must  be  identified.  The  ability  to 
obtain  performance  measures  on  a  performance  objective  is 
one  of  the  factors  you  will  consider  in  deciding  whether  or 
not  to  include  a  task  or  objective  as  an  ET  requirement. 

For  each  performance  objective  in  the  database,  identify 
the  dimension(s)  on  which  the  correct  performance  of  the 
element  can  be  evaluated.  At  this  point,  specific  criteria 
such  as  numeric  values  of  a  performance  measure  are  not 
important.  The  objective  is  to  identify  the  measurement 
variables  for  the  objective.  Standards  dimensions  include 
(but  are  not  limited  to): 

1.  Time  or  speed  of  performance  (e.g.,  completes  procedure 
within  £  seconds). 

2.  Accuracy  or  error  rate  (e.g.,  speed,  heading  deviation, 
mechanical  tolerance,  etc.). 

3.  Safety  considerations. 

4.  Process  measures  (e.g.,  sequence  of  steps  in  a 
procedure,  correct  selection  from  alternatives,  etc.). 

5.  Product  specifications. 

Note  that  particular  objectives  can  have  more  than  one 
dimension  of  correct  performance.  For  example,  some  proce¬ 
dures  may  be  measured  both  by  the  sequence  of  behaviors 
(process)  and  the  time  to  complete  the  procedure. 

As  dimensions  of  performance  are  identified,  add  descrip¬ 
tions  of  the  dimensions  to  the  database  records  of  the 
objectives  . 

Dimensions  of  correct  performance  for  all  objectives 
identified  and  added  to  the  database. 
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SECTION  4 

PROCEDURES  FOR  PHASE  THREE:  IDENTIFY  ETRS  AND  ASSESS 
FEASIBILITY  AND  IMPLEMENTATION  APPROACHES 


An  overview  of  the  steps  performed  in  Phase  Three  is  presented 
graphically  in  Figure  4.  This  Phase  of  the  ETR  identification  process 
consists  of  two  major  subphases.  The  first  subphase  is  concerned  with 
nominat ing  performance  objectives  (at  the  task  or  task-component  level, 
depending  on  whether  Phase  Two  was  performed)  as  ETRs,  using  two 
characteristics  of  objectives:  criticality  and  perishability.  Criti¬ 
cality  refers  to  the  effect  on  the  outcome  of  a  system's  mission  if  an 
objective  is  not  performed,  or  is  performed  incorrectly.  Perishability 
refers  to  the  extent  to  which  a  soldier's  ability  to  perform  an  objec¬ 
tive  correctly  decays  without  periodic  reinforced  practice  of  the 
objective.  An  intermediate  step  is  used  in  identifying  perishability. 
This  step  assigns  each  objective  to  one  of  seven  categories,  based  on 
its  psychological  properties  with  respect  to  retention.  The  first  four 
steps  in  Phase  Three  make  up  this  subphase. 

The  second  subphase  is  concerned  with  assessing,  in  general  terms, 
the  ability  to  implement  the  nominated  ETRs,  and  identifying  candidate 
approaches  to  implement  each  objective  identified  as  suitable  for 
inclusion  in  an  ET  component.  The  final  two  steps  make  up  this 
sub  phase . 

NOTE:  In  evaluating  the  feasibility  of  implementing  the  ETRs, 

there  are  a  number  of  decisions  that  are  made  which  have  potential 
impact  on  the  need  to  include  features  or  capabilities  in  the  prime 
system  design  to  effectively  implement  ET.  These  needs  can  sometimes 
have  a  significant  effect  on  the  design  of  the  prime  item  system.  It 
is  critical  that  materiel  developers  be  made  aware  of  such  needs  very 
early  in  the  system  design  process,  so  that  these  needs  can  be  satis¬ 
fied  by  the  system  design.  Also,  materiel  developers  can  often  provide 
information  about  evolving  system  characteristics  and  capabilities 
which  influence  decisions  about  the  feasibility  of  implementing  objec¬ 
tives  in  the  ET  component.  It  is  critical  that  early  and  frequent 
interaction  between  the  ET  requirements  developer  and  materiel  devel¬ 
opers  take  place  to  insure  that  such  information  is  exchanged.  It  is 
strongly  recommended  that  an  ongoing  dialogue  with  responsible 
personnel  in  materiel  development  for  the  system  (commonly  the  Project 
Manager's  staff)  be  established  at  the  beginning  of  this  phase,  and 
that  this  dialogue  be  continued  throughout  the  remainder  of  the  ETR 
development  process. 

The  subsections  which  follow  present  procedures  for  performing  the 
analyses  and  steps  to  identify  ETRs  for  a  system. 
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Figure  4 
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Overview  of  Phase  Three  procedures. 
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Step  3.1:  Perform  Criticality  Assessment  of  All  Objectives  and 
Annotate  Database 


The  generation  and  use  of  Form  3  (see  Appendix  C)  for  interim  data 
recording  is  suggested  for  this  step 
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Step  3.1:  Perform  Criticality  Assessment  of  All 
Objectives  and  Annotate  Database 


Objective : 

Rationale : 


Procedure : 


Classify  each  performance  objective  in  the  database  as  to 
its  criticality  to  successful  mission  accomplishment. 

Since  a  principal  role  of  ET  will  be  to  provide  sustainment 
training,  the  objectives  that  are  most  important  to 
effective  soldier  performance  must  be  included  in  the  ETRs. 
This  step  identifies  the  general  level  of  criticality  of 
each  performance  objective  to  mission  accomplishment. 

Obtain  a  listing  of  all  the  unique  objectives  in  the 
project  database.  For  each  objective,  evaluate  the  impor¬ 
tance  of  the  objective  to  effective  mission  accomplishment, 
according  to  the  guidance  provided  below.  It  is  critical 
that  SME  judgments  support  the  criticality  classif ications 
in  this  step.  Documentation  generally  cannot  be  relied  on 
to  provide  the  context  needed  to  assess  criticality.  A 
panel  of  two  or  more  SMEs  should  be  used  for  developing 
criticality  judgments,  to  ensure  that  individuals'  unique 
perspectives  do  not  bias  the  results.  If  SME  support  is 
not  available,  perform  this  step  anyway.  However,  if  you 
perform  this  step  without  SME  support,  then  the  certainty 
codes  (see  next  page)  must  be  used  in  conjunction  with 
criticality  classifications.  In  classifying  criticality, 
use  the  following  categories  and  decision  guidance: 

HIGH  criticality  -  Failure  to  perform  the  objective 
correctly  has  a  high  probability  (over  50  percent)  of 
causing  negative  impact  on  the  success  of  the  mission. 

MODERATE  criticality  -  Failure  to  perform  the  objective 
correctly  has  a  moderate  probability  (25  -  50  percent)  of 
causing  negative  impact  on  the  success  of  the  mission. 

LOW  criticality  -  Failure  to  perform  the  objective 
correctly  has  a  low  probability  (less  than  25  percent)  of 
causing  negative  impact  on  the  success  of  the  mission. 

Assign  each  objective  to  one  of  the  three  criticality 
categories.  If  there  is  doubt  about  which  of  the 
categories  an  objective  should  be  assigned  to,  assign  it  to 
the  highest  criticality  category  being  considered. 

As  the  criticality  ratings  are  made,  add  a  code  indicating 
the  level  of  criticality  assigned  to  each  objective  to  the 
appropriate  database  records.  Use  of  the  first  letters  of 
the  three  categories  (H,  M,  L)  is  suggested. 


Product : 


If  incomplete  information  is  used  to  make  the  criticality 
decision,  SME  support  is  not  available,  or  if  there  is 
uncertainty  about  whether  the  assigned  classification  is 
correct  or  valid,  you  may  assign  a  certainty  code  to  the 
criticality  classification.  This  code  can  direct  your 
attention  or  that  of  others  to  specific  objectives  in  later 
iterations  of  ETR  determination  procedures.  This  can  help 
to  ensure  that  the  objectives  needing  specific  attention  at 
a  later  time  do  receive  that  attention. 

If  you  use  a  certainty  code,  add  the  code  as  a  second 
character  to  the  code  for  criticality  classification, 
according  to  the  following  guidance: 

1.  If  you  are  very  certain  of  the  assigned  criticality 
rating  (that  is,  your  decision  is  based  on  positive 
knowledge  of  the  task  and  its  importance  to  the 
mission),  assign  a  certainty  code  of  3  to  the  objec¬ 
tive.  Example:  the  code  M3  indicates  an  objective  of 
Moderate  criticality,  and  the  criticality  judgment  is 
based  on  positive  knowledge  about  the  importance  of 
that  objective  to  the  mission. 

2.  If  you  are  moderately  certain  of  the  assigned  critical¬ 
ity  rating  (your  decision  is  based  on  an  educated 
guess,  or  on  SME  judgments  of  unknown  reliability), 
assign  a  certainty  code  of  2  to  the  objective. 

Example:  the  H2  indicates  a  HIGH  criticality  task,  but 

the  judgment  is  not  totally  reliable  and  needs  further 
validation . 

3.  If  you  are  very  uncertain  of  the  assigned  criticality 
rating  (the  decision  is  based  on  a  complete  guess,  or 
"pulled  out  of  the  hip  pocket"),  assign  a  certainty 
code  of  1  to  the  objective.  Example:  the  code  HI 
indicates  a  task  that  you  believe  to  be  highly 
critical,  but  your  judgment  is  very  unreliable  and 
requires  SME  input  to  be  validated. 

If  possible,  an  independent  review  of  the  criticality 
ratings  by  SMEs  not  involved  in  the  original  ratings 
development  is  desirable.  This  provides  independent 
verification  of  the  criticality  assessments.  If  no 
independent  SME  review  is  possible,  the  personnel  who 
originally  made  the  criticality  judgments  should  review  the 
criticality  data  for  each  objective  after  it  has  been 
entered  into  the  database,  as  verification. 

Criticality  judgments  of  each  objective  assigned,  and 
appropriately  coded  in  the  project  database. 
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Step  3.2: 


Classify  Each  Objective  Per  the  Objectives  Classification 
Guidance  and  Annotate  Database 


The  generation  and  use  of  Fora  3  (see 
recording  is  suggested  for  this  step 


Appendix  C)  for  interim  data 
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Step  3.2:  Classify  Each  Objective  Per  the  Objectives 

Classification  Guidance  and  Annotate  Database 


Objective:  Categorize  each  objective  according  to  its  general  learning 

and  retention  characteristics,  to  support  assessment  of  the 
perishability  of  each  objective. 

Rationale :  Different  kinds  of  skills,  knowledge,  and  abilities  decay 

at  different  rates  when  not  practiced  under  conditions 
where  feedback  is  provided.  Seven  categories  have  been 
defined  which  have  somewhat  different  performance  and 
retention  characteristics  that  impact  on  their  overall 
level  of  perishability.  Each  objective  can  be  classified 
into  one  of  the  seven  categories.  In  addition  to  helping 
in  the  identification  of  perishability,  these  classifica¬ 
tions  also  provide  information  which  is  useful  in  the  later 
design  of  an  ET  component  for  a  system.  The  classifica¬ 
tions  are  performed  at  this  point  to  support  both  uses  of 
the  data. 

NOTE:  If  desired,  this  step  may  be  performed  at  the  same 

time  as  Step  3.1.  The  steps  are  separated  because  of  the 
necessity  of  using  SME  input  for  Step  3.1.  SME  input  is 
not  required  for  this  step,  but  (if  available)  may  be 
useful  in  clarifying  the  category  into  which  a  particular 
objective  should  be  placed,  if  there  is  doubt  about  the 
classification. 

Procedure:  Obtain  a  listing  of  all  objectives  in  the  database.  Using 

the  objectives  classification  guidance  shown  in  Table  1, 
classify  each  objective  into  one  of  the  seven  categories. 
Assign  the  appropriate  nu^ric  code  shown  in  the  classifi¬ 
cation  guidance  table  to  each  objective  as  it  is  classi¬ 
fied.  Enter  the  classification  codes  into  the  database. 

NOTE:  In  some  cases,  the  classification  of  an  objective 

may  appear  ambiguous,  with  the  possibility  that  the 
objective  may  fit  into  more  than  one  classification.  In 
cases  like  this,  assign  the  objective  to  the  classification 
with  the  highest  number  code  being  considered.  This  will 
avoid  "underclassifying"  objectives  as  to  their  level  of 
perishability,  in  the  next  step. 

If  incomplete  information  is  used  to  make  the  objectives 
categorization  decision,  or  if  there  is  uncertainty  about 
whether  the  assigned  categorization  is  correct  or  valid, 
assign  a  certainty  code  to  the  objective  category  code. 

This  code  can  direct  your  attention  or  that  of  others  to 
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Table  1 


Objectives  Classification  Guidance 
Class.  Task,  or 

Code  Objective  Type _ Description 


6  Integrated 

Cognitive  and 
Behavioral  Skills 
Performance 


5  Variable  or 
Contingency 
Cognitive  or 
Behavioral  Skills 
Performance 


4  Rule  or  Concept 

Utilization 


3  Invariant 
Procedures 


Coordinated  task  perform¬ 
ance  requiring  multiple 
complex  cognitive  and/or 
behavioral  skills  whose  use 
is  governed  by  rules;  may 
require  flexible  adaptation 
to  changing  conditions  of 
the  task  or  mission, 
contingency- based 
application  of  rules  in 
dynamic  situations,  or 
rapid  integration  and 
synthesis  of  sensory 
information.  Highly 
perishable. 

Performance  of  procedures 
or  application  of  cognitive 
skills  requiring  flexible 
response  to  a  wide  variety 
of  contingencies  or 
variations  in  conditions  or 
data;  normally  associated 
with  a  single  task  or  skill 
area.  Moderately  to  highly 
perishable. 

Simple  or  complex  classifi¬ 
cation  or  decision  tasks  or 
skills  based  on  applying 
concepts  or  rules  to 
available  information  in 
given  situations. 

Moderately  perishable. 


Specific  procedures 
directed  toward  completing 
one  major  task  or  activity, 
seldom  with  contingencies. 
Performance  is  essentially 
linear  regardless  of  length 
of  procedure.  Low  to 
moderate  perishability. 


_ Examples _ 

Perform  air-to-ground 
weapons  delivery;  plan 
tactical  disposition  of 
units  based  on  latest 
intelligence;  lay 
howitzer  using  manual 
methods;  coordinate 
concentration  of  fires 
from  multiple  sources; 
develop  and  apply 
hypotheses  about  enemy 
plans;  correlate 
information  received 
from  multiple  sources; 
direct  air  strike. 

Start  turbine  engine 
compensating  for 
abnormal  conditions; 
assess  and  correct 
weapon  stoppage;  fault 
isolate  failed  jammer 
subsystem;  set  alert 
criteria;  edit  message 
text;  modify  situation 
map. 

Identify  ground  vehicle 
type  from  seeker  video; 
determine  aspect  of 
airborne  target; 
compute  meteorological 
effects  on  artillery 
fires;  select  munitions 
based  on  target 
characteristics; 
determine  message 
routing. 

Perform  aircraft 
preflight  inspection; 
strip,  clean,  and 
reassemble  M16A2; 
compose  tactical  message 
given  contents;  load  and 
fire  howitzer;  prepare 
mortar  round  for  firing, 
given  charge  and  fuze 
data. 
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Table  1 


Objectives  Classification  Guidance  (Concluded) 


Class.  Task  or 
Code  Objective  Type 


Description 


Examples 


2  Basic  Cognitive 
or  Behavioral 
Skill 


Basic  skills  which  are 
concerned  with  aspects  of 
equipment  operation  or 
performance  of  cognitive 
tasks;  typically  prerequi¬ 
sites  or  components  of 
higher-level  skills.  Low 
perishability. 


Maintain  altitude, 
airspeed,  and  heading; 
load  M16A2;  drive 
self-propelled  howitzer; 
set  up  mine  detector; 
track  target  using 
seeking  video  and 
joystick;  read  at  8th 
grade  level;  recall 
password;  type  command 
into  computer. 


1  Knowledges 


Facts  of  any  type 
concerning  equipment 
structure,  characteristics, 
and  operation,  specific 
aspects  of  mission  perform¬ 
ance,  or  general  (as 
opposed  to  situation- 
specific)  data.  Low 
perishabi lity . 


State  operational  range 
of  the  AH-64;  locate  the 
turret  traverse  switch; 
recall  maximum  allowable 
service  hydraulic 
pressure;  recall 
reported  location  of 
OPFOR  elements;  state  of 
available  intelligence 
sources . 


0  Basic  Level  Psychomotor  or  cognitive  Set  MODE  switch  to 

Behaviors  task  components  at  a  lower  DIAGNOSTICS  (component 

level  than  subtasks  or  of  a  checkout  pro¬ 

procedures  (not  knowledges)  cedure);  verify  landing 
which  would  not  be  gear  indicator  shows 

evaluated  independent  from  DOWN  AND  LOCKED 
the  subtasks  or  procedures  (component  of  procedure 
of  which  they  are  to  lower  landing  gear); 

components.  NOTE:  Basic  enter  function  code 

Level  Behaviors  are  (portion  of  a  computer 

included  here  to  discrimi-  operation  procedure); 
nate  them  from  tasks,  find  row  and  column 

subtasks,  procedures  and  intersections  in  a  table 
objectives  that  are  used  in  (part  of  a  procedure  in 
determining  ETRs.  Basic  data  analysis), 

level  behaviors  may  be 
identified,  but  should  not 
be  considered  in  ETR 
determinations. 
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specific  objectives  in  later  iterations  of  ETR  determina¬ 
tion  procedures.  This  can  help  to  ensure  that  the  objec¬ 
tives  needing  specific  attention  at  a  later  time  do  receive 
that  attention. 

If  you  use  a  certainty  code,  add  the  code  as  a  second 
character  to  the  code  for  objective  categorization, 
according  to  the  following  guidance: 

1.  If  you  are  very  certain  of  the  assigned  categorization 
(that  is,  your  decision  is  based  on  positive  knowledge 
of  the  objective  and  its  characteristics),  assign  a 
certainty  code  of  3  to  the  objective.  Example:  the 
code  53  indicates  an  objective  classified  as  a  Variable 
or  Contingency  Cognitive  or  Behavioral  Skills  Perform¬ 
ance,  and  the  categorization  is  based  on  positive 
knowledge  about  the  characteristics  of  the  objective. 

2.  If  you  are  moderately  certain  of  the  assigned  categori¬ 
zation  (your  decision  is  based  on  an  educated  guess,  or 
on  data  of  unknown  reliability),  assign  a  certainty 
code  of  2  to  the  objective.  Example:  the  code  42 
indicates  a  task  categorized  as  a  Rule  or  Concept 
Utilization,  but  the  judgment  is  not  totally  reliable 
and  needs  further  validation. 

3.  If  you  are  very  uncertain  of  the  assigned  categoriza¬ 
tion  (the  decision  is  based  on  a  complete  guess,  or 
"pulled  out  of  the  hip  pocket"),  assign  a  certainty 
code  of  1  to  the  objective.  Example:  the  code  61 
indicates  a  task  that  you  believe  to  be  an  Integrated 
Cognitive  and  Behavioral  Skills  Performance  task,  but 
the  judgment  is  very  unreliable  (possibly  based  on  very 
incomplete  data),  and  requires  specific  data  in  order 
to  be  validated. 

Product'  Claow  i  Tlv_.it  ion  roHec  ^.--igned  to  all  objectives,  and 
entered  in  the  project  database. 
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Step  3. 


Use  Objective  Classifications  to  Make  Perishability 
Judgments  and  Annotate  Database 
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Step  3.3:  Use  Objective  Classifications  to  Hake 

Perishability  Judgments  and  Annotate  Database 


Ob j ective : 
Rat ionale : 

Procedure : 


Product : 


Identify  the  level  of  perishability  of  each  objective. 

Criticality  (identified  in  Step  3.1)  and  perishability  are 
the  two  factors  used  to  nominate  objectives  for  inclusion 
in  an  ET  component. 

Using  the  capabilities  of  the  database  management  software 
in  use,  or  manually  if  necessary,  examine  the  objective 
classifications  made  in  Step  3.2  (field  in  the  database 
records  for  objectives).  Classify  the  perishability  of 
each  objective,  and  annotate  the  database,  according  to  the 
following  rules: 

1.  An  objective  is  HIGH  perishability  if  it  is  classified 
as  an  Integrated  Cognitive  and  Behavioral  Skills 
Performance,  classification  code  6.  Insert  the  code  H 
in  the  database  record  field  for  perishability 
classification . 

2.  An  objective  is  MODERATE  perishability  if  it  is  classi¬ 
fied  as  a  Variable  or  Contingency  Cognitive  or 
Behavioral  Skill  Performance  (classification  code  5)  or 
a  Rule  or  Concept  Utilization  (classification  code  4). 
Insert  the  code  M  in  the  database  record  field  for 
perishability  classification. 

3.  An  objective  is  LOW  perishability  if  it  is  classified 
as  an  Invariant  Procedure  (classification  code  3),  a 
Basic  Cognitive  or  Behavioral  Skill  (classification 
code  2),  or  a  Knowledge  (classification  code  1). 

Insert  the  code  L  in  the  database  record  field  for 
perishability  classification. 

Basic  Level  Behaviors  (classification  code  0)  are  not  rated 
for  perishability,  but  should  be  retained  in  the  database, 
if  they  have  already  been  identified. 

Perishability  levels  identified  for  each  objective,  and 
appropriate  codes  added  to  the  project  database. 
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Step  3.4: 


Use  Perishability  and  Criticality  Judgments 
to  Nominate  Objectives  for  ET;  Annotate  Database 


Q°"0 


Complete  Diubu* 


Step  3.4:  Use  Perishability  and  Criticality  Judgments  to 
Nominate  Objectives  for  ET ;  Annotate  Database 


Ob j  ect ive : 


Rationale : 


Procedure : 


Product : 


Identify  the  objectives  in  the  database  which  have  either 
High  or  Moderate  criticality  o£  High  or  Moderate  perish¬ 
ability,  and  designate  those  objectives  as  nominated  for 
inclusion  in  the  ETRs . 

High  or  Moderate  objectives  and  High  or  Moderate  perish¬ 
ability  objectives  are  the  best  candidates  for  including  in 
the  ETRs.  This  is  due  to  the  fact  that  many  ET  components 
will  be  used  for  sustainment  training  in  the  unit  environ¬ 
ment,  after  initial  skills  have  been  acquired  elsewhere. 

To  maximize  personnel  readiness  to  perform  combat  missions, 
critical  and  perishable  skills  must  be  maintained  at  high 
levels  by  sustainment  training. 

Using  the  capabilities  of  the  database  management  software 
in  use  (or  manually,  if  necessary),  examine  the  perishabil¬ 
ity  and  criticality  classifications  for  each  objective. 
Using  the  following  rule,  annotate  the  database  record  for 
each  objective  as  to  whether  the  objective  is  selected  as 
nominated  as  an  ETR,  or  not. 

If  the  criticality  classification  code  is  High  or  Moderate 
or  if  the  perishability  classif ication  code  is  High  or 
Moderate,  identify  the  objective  as  selected  as  an  ETR  by 
placing  a  Y  code  in  the  database  record  field  used  for  that 
purpose  (normally  a  "Selected  for  ET"  field).  If  both  the 
criticality  and  perishability  codes  are  Low,  identify  the 
objective  as  not  selected  as  an  ETR  by  placing  an  N  code  in 
the  database  record  field. 

Identification  of  each  objective  as  nominated  for  ET  (or 
not)  and  appropriate  annotation  of  the  records  of  the 
project  database. 
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Step  3. 


:  Use  Other  ET  Factors  to  Assess  Nominated  Objectives 
Feasibility  and  Identify  Implementation  Approaches 
ET;  Annotate  Database 


The  generation  and  use  of  Form  5  (see  Appendix  C)  for  interim  dat 
recording  is  suggested  for  this  step 


Seep  3.5:  Use  Other  ET  Factors  to  Assess  Nominated  Objectives 

Feasibility  and  Identify  Implementation  Approaches  in 
ET ;  Annotate  Database 


Ob  jective :  Perforin  an  initial  assessment  of  the  feasibility  of 
implementing  each  objective  nominated  as  an  F.TR,  and 
identify  potentially  suitable  approaches  to  implementation 
of  the  ETRs . 

Rationale :  The  ETR  nomination  performed  in  Step  3.4  considers  only 

perishability  and  criticality,  and  does  not  deal  with 
implementing  the  nominated  ETRs.  This  step  provides  an 
initial  assessment  of  each  of  the  ETR-nominated  objectives, 
from  the  viewpoint  of  potential  requirements  to  include  the 
objective  in  an  ET  component.  The  analysis  here  is  done  at 
a  gross  level  in  an  attempt  to  exclude  obviously  unsuitable 
objectives.  This  also  allows  you  to  make  an  initial 
estimate  of  the  proportion  of  ETR-nominated  objectives  that 
will  be  straightforward  to  implement,  and  those  that  will 
be  difficult  to  implement. 

These  analyses  assume  that  general  characteristics  of  the 
soldier-machine  interface(s)  of  the  target  system  can  be  at 
least  estimated.  That  is,  a  concept  of  how  the  soldier 
interacts  with  the  target  system,  and  with  the  environment 
in  which  the  target  system  will  operate,  should  be  avail¬ 
able.  For  example,  if  most  input  is  provided  to  a  soldier 
through  a  video  display,  or  if  the  soldier  sees  direct-view 
or  optically  relayed  images  of  the  visual  environment 
outside  the  system,  these  are  important  characteristics  of 
the  way  task  stimuli  are  presented  by  the  system.  The  ways 
the  operator  controls  the  system  are  also  important  charac¬ 
teristics  that  should  be  considered.  If  discrete  actions 
(like  moving  a  joystick  or  pressing  keys)  performed  by  a 
soldier  can  be  sensed  by  the  ET  software,  it  is  likely  that 
sensing  operator  actions  can  be  relatively  straightforward. 
On  the  other  hand,  if  the  result  of  an  operator  task  is  a 
decision  or  spoken  language,  it  may  be  impossible  for  the 
ET  software  to  sense  the  outcome. 

If  it  is  possible  to  have  at  least  a  gross  concept  of  the 
ways  the  soldier  interacts  with  the  system,  this  step 
should  be  accomplished.  Sometimes,  early  in  the  acquisi¬ 
tion  process,  this  kind  of  information  simply  is  not  avail¬ 
able.  If  a  concept  of  the  soldier-machine  interface  is  not 
available,  then  this  step  may  be  bypassed.  If  this  step  j_s 
bypassed,  this  should  be  clearly  stated  when  reporting  the 
ET  requirements  identified  by  this  process.  Assessment  of 
the  feasibility  of  implementing  the  various  ETRs  will  have 
to  be  made  during  preliminary  design  of  the  ET  component, 
if  it  is  not  done  here. 
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Procedures : 


Obtain  a  listing  from  the  database  of  each  objective 
nominated  as  an  ETR  in  Step  3.4.  This  listing  must  include 
the  complete  objective  statement,  and  the  conditions  and 
(if  Phase  Two  has  been  performed)  standards  of  performance 
for  each  objective.  This  information  will  be  required  ro 
make  some  of  the  judgments  in  the  substeps  that  follow.  An 
overview  of  the  implementation  and  feasibility  decision 
algorithm  that  is  used  to  address  the  tasks  and  objectives 
is  shown  in  Figure  5.  Study  the  algorithm  until  you  are 
comfortable  that  you  understand  its  structure  and  the 
decisions  that  must  be  made  to  go  through  the  algorithm. 
After  you  are  familiar  with  the  algorithm,  follow  the 
procedures  below. 

NOTE:  It  is  often  useful  to  deal  with  these  decisions  on  a 

global  basis  before  performing  detailed  analyses  at  the 
task  or  objective  level.  In  some  cases,  it  may  not  be 
necessary  to  apply  all  of  the  decision  questions,  if  you 
decide  that  the  characteristics  of  the  target  system  or  the 
tasks  under  consideration  support  a  global  decision  about 
some  implementation  factors. 

For  example,  if  you  are  dealing  with  a  target  system  where 
personnel  only  interact  with  a  computer  terminal  or  a 
console,  it  is  probably  not  necessary  to  consider  whether 
providing  visual  or  auditory  simulation  of  the  non¬ 
equipment  environment  is  needed  for  effective  training.  In 
such  a  case,  the  questions  dealing  with  visual  and  auditory 
environment  simulation  requirements  could  be  omitted. 

If  you  can  make  this  kind  of  global  decision,  you  can 
shorten  the  analysis  process  so  that  all  questions  do  not 
have  to  be  asked  for  all  objectives  which  are  nominated  as 
possible  ETRs .  Before  you  "tailor"  these  procedures  by 
omitting  decision  questions,  however,  review  the  nominated 
ETRs  and  the  characteristics  of  the  target  system,  and 
ensure  that  questions  that  you  consider  omitting  are  not 
relevant  to  providing  effective  training. 

If  you  are  able  to  "tailor"  the  decision  algorithm,  you 
will  be  able  to  omit  some  of  the  steps  below.  But,  you 
should  study  all  of  the  steps  before  omitting  any  of  them 
so  that  you  will  ask  the  correct  questions  in  your 
"tailored"  procedures.  If  you  do  not  "tailor"  the  decision 
algorithm,  follow  the  exact  sequence  of  questions  and 
decisions  shown  below,  for  each  objective  nominated  as  a 
possible  ETR. 
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Substep  A  -  Decide  whether  providing  the  stimuli  needed  to 
perform  the  objective  on  the  target  system  equipment  is 
feasible.  At  this  point,  do  not  cl  ~sider  stimuli  that  a 
soldier  may  get  from  other  sources  than  the  system 
equipment .  This  will  be  considered  at  a  later  step  in  the 
algorithm.  For  example,  if  most  information  is  presented 
to  soldiers  by  means  of  visual  display  units  (VDUs), 
implementing  ET  will  probably  be  fairly  easy.  On  the  other 
hand,  if  most  information  comes  from  "round  dial"  displays, 
ET  may  be  somewhat  be  harder  to  implement.  A  general 
guideline  to  use  is  that  anything  in  terms  of  system 
displays  that  is  presented  or  controlled  by  a  computer  or 
microprocessor  can  probably  be  implemented  fairly  easily. 
This  includes  such  things  as  lighted  pushbuttons  or 
function  switches,  in  addition  to  VDU  displays,  etc. 

NOTE:  If  this  analysis  is  being  done  in  early  phases  of 

system  development  (e.g.,  concept  formulation),  it  may  be 
possible  to  provide  additional  capabilities  to  implement  an 
ET  component.  Do  not  assume  that  stimuli  for  an  objective 
cannot  be  implemented  without  some  positive  evidence  that 
this  is  true.  It  is  recommended  that  materiel  developers 
be  consulted  throughout  the  process  of  determining  whether 
it  is  feasible  to  implement  aspects  of  an  ET  component  on 
the  system. 

If  you  judge  that  it  i_s  feasible  to  present  the  stimuli 
needed  to  perform  the  objective,  then  go  on  to  Substep  B 
below. 

If  you  decide  that  it  is  not  feasible  to  present  the 
equipment  stimuli,  you  have  decided  that  the  objective  is 
not  feasible  to  include  in  ET.  When  you  make  this 
decision,  annotate  the  objective  "ET  Feasibility  Judgment" 
field  in  the  appropriate  database  record  with  the  code  "I." 

This  indicates  that  the  objective  is  judged  infeasible  for 
implementation. 

Substep  B  -  Decide  whether  providing  the  objective  as  part 
of  the  ET  component  could  result  in  hazards  to  personnel  or 
the  possibility  of  damaging  the  system  or  other  equipment. 

To  make  this  judgment,  you  will  need  to  imagine  or  form  a 
concept  about  how  the  system  might  be  used  in  training,  and 
how  including  an  objective  in  ET  could  be  hazardous  to 
personnel  or  equipment.  Consider  the  conditions  under 
which  the  objective  is  performed  in  developing  this 
concept.  For  example,  if  you  are  considering  an  aviation 
system,  and  providing  visual  stimuli  on  a  heads-up  display 
to  train  an  objective  in-flight  would  be  required,  consider 
whether  the  stimuli  could  obscure  a  crewmember’s  ability 
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to  see  safety-related  cues  in  the  outside  world.  A  general 
guideline  that  can  be  used  is:  if  the  system  is  in  motion 
during  an  objective,  or  the  objective  causes  gross  physical 
movement  of  the  equipment  or  its  parts,  it  is  possible  that 
a  hazard  could  be  created  if  the  objective  were  included  in 
ET.  Another  useful  guideline  is:  if  an  objective  requires 
live  fire  of  weapons  or  handling  of  live  ordnance,  there 
could  be  a  safety  compromise  if  the  objective  is  included 
in  ET.  Consultation  with  materiel  developers  may  help  to 
develop  concepts  about  implementation  safety. 

The  guidelines  above  should  not  be  thought  of  as  ruling  out 
simulation  of  damage  to  the  system  as  part  of  an  embedded 
training  exercise.  For  example,  it  may  be  a  useful  form  of 
feedback  to  provide  simulated  indications  that  erroneous 
operator  actions  have  caused  the  system  to  be  damaged,  or 
in  an  abnormal  state.  Actual  damage  to  the  system  would, 
of  course,  not  take  place.  Also,  simulated  malfunction 
indications  might  be  used  to  provide  stimuli  for  mainte¬ 
nance  fault  isolation  tasks. 

If  you  judge  that  the  possibility  of  safety  compromise  does 
not  exist  for  an  objective,  or  that  safety  compromise  is 
unlikely ,  then  go  on  to  Substep  C  below. 

If  you  judge  that  safety  compromise  is  a  significant 
possibility  if  an  objective  is  included  in  ET,  then  you 
have  decided  that  the  objective  must  not  be  included  in  ET. 
When  you  make  this  decision,  annotate  the  objective  "ET 
Feasibility  Judgment"  field  in  the  appropriate  database 
record  with  the  code  "S."  This  indicates  that  the 
objective  has  been  excluded  from  further  consideration  for 
ET  because  of  the  likelihood  of  safety  compromise. 

Substep  C  -  Decide  whether  meaningful  performance  measures 
and  criteria  can  be  defined  for  the  objective.  In  this 
case,  meaningful  refers  to  the  ability  to  identify  the  way 
a  soldier  performs  an  objective,  by  sensing  the  soldier’s 
actions  or  identifying  specific  outcomes  of  the  soldier's 
behavior.  Such  actions  or  outcomes  reflect  how  well  the 
soldier  has  performed.  When  making  this  decision,  you 
should  consider  more  than  just  gross-scale  "tactical" 
measures  of  performance,  such  as  the  number  of  targets 
killed  versus  the  number  presented.  A  useful  guideline  in 
this  decision  is:  if  it  is  possible  to  sense  the  actions 
the  soldier  takes  in  performing  an  objective,  and  relate 
those  actions  to  the  outcome  of  the  soldier's  performance, 
then  there  is  a  good  chance  that  meaningful  performance 
measures  can  be  derived.  You  should  consider  that  any 


action  performed  by  a  soldier  which  causes  a  physical 
change  in  the  controls  the  soldier  interacts  with  (e.g., 
changing  the  position  of  a  switch,  moving  a  joystick, 
typing  in  a  command  on  a  keyboard)  could  be  sensed  by  an  ET 
component.  Response  sensing  serves  as  signals  for  evalua¬ 
ting  performance  or  adaptively  modifying  the  training 
situation.  As  in  the  safety  compromise  judgment  in  Substep 
B,  it  may  be  useful  to  develop  a  "scenario"  of  how  a 
soldier  would  perform  the  objective,  and  what  equipment 
would  be  involved. 

If  you  judge  that  meaningful  performance  measures  can  be 
derived  by  sensing  and  interpreting  operators'  actions, 
then  proceed  on  to  Substep  D. 

If  you  decide  that  meaningful  performance  measures  cannot 
be  derived  by  sensing  and  interpreting  operators'  actions, 
then  proceed  to  Substep  E. 

Substep  D  -  Decide  whether  it  is  feasible  to  perform 
assessment,  scoring,  and  real-time  feedback  of  performance 
related  to  the  objective.  Performance  assessment  and  feed 
back  are  extremely  valuable  features  of  an  ET  component,  so 
this  decision  can  be  crucial.  Although  the  decision  is 
crucial,  the  information  needed  to  make  the  decision  is 
often  not  available. 

The  actual  determination  as  to  whether  it  will  be  feasible 
to  provide  capabilities  for  assessment,  scoring,  and  feed¬ 
back  of  trainee  performance  will  rest  with  overall  system 
capabilities.  In  case  of  doubt  as  to  whether  such  capabil¬ 
ities  will  be  made  available,  it  is  strongly  suggested  that 
discussions  with  the  system  materiel  developers  be  held. 

If  there  is  a  potential  need  to  make  special  provision  for 
these  training  support  capabilities,  requirements  for  the 
system  can  sometimes  be  augmented  to  provide  the  needed 
capabilities.  However,  it  is  extremely  important  to  make 
such  inputs  to  materiel  developers  early  in  the  system 
acquisition  process,  so  that  expensive  design  changes  later 
in  the  development  cycle  can  be  avoided. 

It  appears,  in  most  cases,  that  the  limiting  factor  on  this 
decision  is  the  amount  of  computer  processing  capability 
and  storage  available  through  the  system  or  via  the  ET 
component.  It  is  perhaps  wise  to  make  this  decision  on  a 
global  basis.  The  question  to  ask  is:  will  there  be 
processing  and  storage  capacity  available  to  support 
assessment,  scoring,  and  feedback  in  general?  Frequently, 
even  such  a  high-level  decision  will  be  impossible.  If  it 
is  not  possible  to  make  a  decision  at  this  point  at  either 
an  objective  level  or  a  global  level,  skip  this  decision, 
and  assume  that  all  desirable  assessment ,  performance 
scoring,  and  feedback  capabilities  are  possible.  However, 
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if  this  decision  is  made,  do  not  neglect  to  perform  Substep 
E  for  objectives  for  which  developing  performance  measures 
and  criteria  is  not  possible.  Also,  note  that  this 
assumption  was  made. 

If  you  judge  that  performance  assessment,  scoring,  and 
feedback  are  possible  for  specific  objectives,  proceed  to 
Substep  F. 

If  you  have  made  a  general  judgment  that  performance 
assessment,  scoring,  and  feedback  are  possible  through  the 
equipment  or  the  ET  component  at  large,  also  proceed  to 
Substep  F. 

If  you  judge  that  performance  assessment,  scoring,  and 
feedback  are  NOT  possible  for  specific  objectives,  proceed 
to  Substep  E. 

Substep  E  -  For  objectives  where  either:  (a)  meaningful 
performance  measures  and  criteria  cannot  be  derived  by 
measuring  soldiers'  actions;  or  (b)  performance  assessment, 
scoring,  and  feedback  are  not  possible  through  the  ET 
component  for  a  particular  objective,  decide  whether  the 
soldiers  performing  the  objective,  or  an  over-the-shoulder 
observer  or  instructor,  can  provide  effective  performance 
assessment  and  feedback. 

Since  ET  will  commonly  be  used  for  sustainment  training,  it 
is  possible  that  soldiers  may  be  proficient  enough  to 
evaluate  their  own  performance  and  diagnose  their  own 
errors,  in  some  cases.  Also,  if  the  ET  component  cannot 
provide  performance  assessment,  scoring,  and  feedback,  it 
may  be  possible  to  provide  an  instructor  or  observer  to  do 
so. 


Two  guidelines  are  useful  in  making  this  decision.  In  the 
case  where  you  are  considering  whether  the  soldiers  them¬ 
selves  can  assess  their  own  performance,  decide  whether: 

(a)  in  a  crew  situation,  some  crewmembers  are  likely  to  be 
more  proficient  or  senior  than  others;  or  (b)  in  any  situa¬ 
tion,  the  overall  level  of  proficiency  and  expertise  of 
task  performers  is  likely  to  be  high.  If  either  of  these 
considerations  is  true,  self-assessment  potential  is  high, 
and  It  is  probably  feasible  to  allow  crewmembers  or 
individual  soldiers  to  assess  their  own  performance  in  an 
ET  environment. 

In  the  case  where  you  are  considering  the  possibility  of 
over-the-shoulder  evaluation,  consider  whether  it  is 
possible  for  an  evaluator  to  observe  exactly  what  situa¬ 
tions  and  stimuli  are  presented  to  the  trainee,  and  what 
the  trainee's  actions  and  behaviors  are.  If  this  is  judged 
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to  be  the  case,  then  the  probability  of  successful  over- 
the-shoulder  evaluation  is  high.  Whether  it  is  feasible  to 
provide  over-the-shoulder  evaluation  from  other  standpoints 
(such  as  personnel  requirements  or  cost)  should  not  be 
considered  at  this  time. 

If  you  judge  that  self-assessment  or  over-the-shoulder 
evaluation  is  reasonably  feasible,  you  have  identified  the 
objective  as  suitable  for  ET  with  off-line  performance 
measurement .  When  you  make  this  decision,  annotate  the 
objective  "ET  Feasibility  Judgment"  field  in  the  appropri¬ 
ate  database  record  with  the  code  "0."  This  indicates  that 
the  objective  has  been  judged  feasible  for  ET  implementa¬ 
tion  with  Off-line  performance  measurement. 

If  you  judge  that  self-assessment  or  over-the-shoulder 
evaluations  are  not  possible  for  a  given  objective,  the 
value  of  including  the  objective  in  an  ET  component  is 
questionable.  If  this  decision  is  reached,  the  objective 
will  be  retained  in  the  ETRs  for  the  time  being,  but  will 
be  coded  specifically  to  reflect  that  performance  measure¬ 
ment  is  not  considered  possible.  When  yo"  make  this 
decision,  annotate  the  objective  "ET  Feasibility  Judgment" 
field  in  the  appropriate  database  record  with  the  code  "Q." 
This  indicates  that  the  objective  is  Questionable  from  the 
viewpoint  of  performance  measurement. 


Substep  F  -  Decide  whether  the  objective  requires  simula¬ 
tion  of  any  aspects  of  the  visual  or  auditory  environment 
external  to  the  equipment  to  provide  all  needed  stimuli  to 
accomplish  the  task  or  objective.  This  includes  such 
stimuli  as  out-the-window  views  of  the  environment,  images 
from  remote  or  indirect  sources  such  as  cameras  or  infrared 
sensors,  weapons  firing  sounds  or  visual  impact  signatures, 
or  any  other  completely  external  stimuli.  In  general,  such 
stimuli  are  difficult  and  costly  to  provide,  so  the  need 
for  them  must  be  carefully  considered.  However,  if  static 
images  are  required,  it  is  more  feasible  and  less  costly  to 
provide  them  than  if  dynami c  images  are  required. 

In  making  this  judgment,  knowledge  of  the  stimuli  which  are 
present  in  the  actual  task  performance  situation  is  criti¬ 
cal.  Use  the  conditions  of  performance  data  provided  for 
each  objective  to  support  this  decision.  "Scenarios"  of 
how  the  objective  is  performed,  and  how  the  soldier  inter¬ 
acts  with  the  equipment  and  the  performance  environment  may 
be  useful  in  making  this  decision.  In  general,  if  a 
soldier  receives  stimuli  from  a  source  outside  the  equip¬ 
ment  itself  which  are  critical  to  objective  performance. 
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then  it  will  probably  be  necessary  to  simulate  those 
stimuli  in  the  ET  component. 

If  you  judge  it  is  necessary  to  provide  visual  or  auditory 
environment  stimuli  in  order  to  present  the  objective  to 
the  trainee,  proceed  on  to  Substep  G. 

If  it  is  not  necessary  to  provide  visual  or  auditory 
environment  stimuli,  then  you  have  finished  with  the 
decisions  for  this  objective.  When  you  make  this  decision, 
annotate  the  objective  "ET  Feasibility  Judgment"  field  in 
the  appropriate  database  record  with  the  code  "H."  This 
indicates  that  the  objective  is  a  High-priority  candidate 
for  implementation  in  the  ET  component,  and  is  retained  as 
an  ETR. 

Substep  G  -  Decide  whether  providing  the  needed  visual  or 
auditory  stimuli  is  likely  to  be  feasible.  There  are  two 
aspec.s  of  the  stimuli  and  the  objective  situation  to 
consider  in  making  this  decision.  The  first  is  whether  a 
static  representation  of  the  visual  environment  can  be 
used,  or  whether  a  dynamic  representation  is  required. 
(Auditory  stimuli  cannot  be  static.)  If  visual  motion  of 
any  portion  of  the  external  environment  has  to  be 
simulated,  then  a  dynamic  representation  is  required.  If  a 
completely  static  representation  of  the  "outside  visual 
world"  will  do,  then  it  is  probably  feasible  to  provide 
that  presentation. 

As  with  assessment,  scoring,  and  feedback  capabilities,  the 
implementation  of  visual  and  auditory  simulation  require¬ 
ments  interacts  strongly  with  system  characteristics.  If 
visual  and  auditory  stimulation  requirements  are  identified 
as  necessary  for  implementing  ET,  it  is  strongly  suggested 
that  these  requirements  be  made  known  to  materiel  devel¬ 
opers  as  early  as  possible.  If  early  identification  of 
these  requirements  is  made,  it  may  be  feasible  to  augment 
system  capabilities  to  make  presentation  of  such  stimuli 
possible,  or  to  provide  for  these  capabilities  in  the 
system  design.  The  decision  to  implement  these  capabili¬ 
ties  must  be  coordinated  with  the  materiel  developers, 
however.  Providing  simulation  capabilities  to  support  ET 
may  have  significant  impacts  on  system  design,  and 
knowledge  of  possible  requirements  for  these  capabilities 
is  essential  in  the  design  trade-off  process  for  the 
system.  Decisions  about  including  these  capabilities 
should  be  made  jointly  with  materiel  developers. 

If  a  dynamic  representation  of  either  auditory  or  visual 
aspects  of  the  external  environment  is  required,  then  the 
required  level  of  fidelity  of  presentation  must  be 
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considered  in  judging  feasibility.  If  a  soldier  will  have 
to  use  the  representation  to  make  fine  judgments  about  the 
characteristics  or  dynamic  nature  of  what  is  presented, 
then  a  high-fidelity  presentation  will  be  required. 

Examples  include  discriminating  subtle  visual  character¬ 
istics  to  classify  targets  by  their  visual  signatures,  and 
judging  by  sound  how  many  rounds  have  been  fired  from  an 
automatic  weapon. 

If  the  soldier  will  only  be  required  to  make  gross  judg¬ 
ments  about  the  presence  or  absence  of  major  features  of 
the  environment  representation,  then  a  lower  level  of 
fidelity  will  be  required.  Examples  include  judging 
whether  artillery  aiming  stakes  are  lined  up  in  a  sight 
reticle,  and  discriminating  the  presence  of  an  auditory 
warning  tone  from  background  noise. 

Visual  and  auditory  fidelity  decisions  can  be  difficult, 
and  the  examples  above  are  extremes;  there  are  many  points 
between  them  on  the  fidelity  continuum.  In  general, 
consider  the  fineness  of  judgment  about  the  external 
environment  that  the  soldier  will  have  to  make,  given  what 
is  presented.  The  finer  the  judgment,  in  general,  the 
higher  the  fidelity  required  in  the  stimulus  presentation, 
and  the  lower  the  feasibility  of  providing  the  needed 
stimuli  will  be  (other  things  being  equal). 

If  you  decide  that  it  is  at  least  marginally  feasible  to 
consider  including  the  needed  level  of  fidelity  in  simulat¬ 
ing  the  external  environment,  then  you  have  classified  the 
objective  being  considered  as  a  good  candidate  for  ET.  It 
will  be  retained  in  the  ETR.  When  you  make  this  decision, 
annotate  the  objective  "ET  Feasibility  Judgment"  field  in 
the  appropriate  database  record  with  the  code  "T."  This 
indicates  that  the  objective  will  require  simulation  of 
exTernal  auditory  or  visual  stimuli,  but  that  providing 
that  simulation  is  considered  feasible. 

If  you  decide  that  it  is  probably  not  feasible  to  include 
the  needed  level  of  simulation  fidelity,  then  you  have 
contingently  excluded  the  objective  being  considered  from 
the  ETRs .  Some  subtasks  or  lower-level  objectives  that  are 
subordinate  to  an  objective  may  still  be  good  candidates 
for  inclusion,  however,  and  should  be  carefully  considered, 
in  turn.  When  you  make  this  decision,  annotate  the 
objective  "ET  Feasibility  Judgment"  field  in  the  appropri¬ 
ate  database  record  with  the  code  "X."  This  indicates  that 
the  objective  has  been  excluded  from  further  consideration 
for  ET  because  providing  the  needed  external  environment 
stimuli  is  probably  not  feasible. 
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Product : 


At  this  point,  all  decisions  in  this  step  about  the 
objective  under  consideration  are  complete.  Proceed  to 
analyze  the  next  objective  on  the  listing. 

ET  feasibility  and  implementation  approach  judgments,  coded 
and  added  to  the  project  database. 
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Step  3.6:  Review  Selected  Objectives  to  Validate  and  Remove 
Inconsistencies;  Modify  and  Finalize  Database 


The  generation  and  use  of  Form  6 


(see  Appendix  C) 


is  recommended 
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Step  3.6:  Review  Selected  Objectives  to  Validate  and 
Remove  Inconsistencies;  Modify  and 
Finalize  Database 


Ob  j  ec  t i ve :  Identify  ETR  selection  anomalies  among  the  objectives, 

correct  the  anomalies,  and  validate  the  project  database. 

Rat ionale :  In  some  cases,  the  strict  nomination  criteria  for  ETRs 

(perishability  and  criticality)  will  not  nominate  all  of 
the  objectives  which  are  above  a  nominated  lower-level 
objective.  This  is  a  mistake:  if  a  lower-level  objective 
is  nominated  as  an  ETR,  then  all  of  the  objectives  superior 
to  it  in  the  hierarchy  should  be  nominated,  as  well.  A 
lower-level  component  being  validly  nominated  as  an  ETR 
should  result  in  all  of  the  components  above  it  in  the 
hierarchy  being  nominated. 

The  reverse  case,  where  a  higher-level  objective  is 
nominated,  but  lower-level  objectives  are  not  nominated,  is 
not  a  cause  for  concern.  A  perishable  or  critical  aspect 
of  performance  can  have  some  non-perishable  or  non-critical 
components . 

This  step  will  identify  cases  where  low-level  objectives 
are  nominated,  but  elements  superior  to  them  in  the 
hierarchy  are  not.  Then,  the  hierarchy  will  be  examined  to 
identify  the  source  of  the  problem  and  it  will  be 
corrected . 

Procedure :  Obtain  a  listing  of  the  entire  database,  indexed  by  hier¬ 

archy  codes.  As  a  minimum,  codes,  objective  statements, 
criticality  judgments,  objectives  classifications,  perish¬ 
ability  judgments,  ET  nomination  codes,  and  feasibility 
codes  should  be  included  in  this  listing.  Then,  examine 
the  objectives  hierarchy  in  detail,  and  identify  all  cases 
where  lower-level  objectives  are  nominated  as  ETRs  and 
higher-level  elements  above  them  in  the  hierarchy  are  not 
nominated . 


For  each  case  where  this  occurs,  examine  the  criticality 
and  perishability  judgments  and  the  objectives  classifi¬ 
cation  for  the  lower-level  objective  first.  Determine  if  a 
mistake  has  been  made  in  assigning  codes  for  any  of  these 
data  items.  Also,  determine  if  wrong  judgments  may  have 
led  to  the  assignment  of  the  erroneous  codes. 

If  it  turns  out  that  the  only  error  is  in  coding  or 
judgment  of  one  or  more  factors  for  the  lower-level 
objective,  simply  correct  the  appropriate  items  in  the 
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Product : 


database.  This  is  the  most  likely  case  if  the  preceding 
steps  have  been  done  conscientiously. 

Otherwise,  it  will  be  necessary  to  examine  each  of  the 
objectives  superior  to  the  lower-level  objective,  determine 
where  erroneous  judgments  have  been  made  or  wrong  database 
codes  have  been  inserted,  and  correct  all  problems  that  are 
found . 

As  the  database  is  examined,  also  look  for  minor  errors 
such  as  misspellings  and  missing  information.  Correct  any 
such  errors,  where  possible.  The  database  will  be  used  to 
support  the  design  of  the  ET  component.  Thus,  it  should  be 
comprehensive,  accurate,  and  complete  at  the  end  of  this 
step. 

The  final  analysis  database,  reflecting  the  performance 
objectives  hierarchy,  all  judgments  made  in  the  ETR  defini¬ 
tion  process,  the  nominated  ETRs,  and  tne  implementation 
judgments . 
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SECTION  5 

PHASE  FOUR:  FINAL  DOCUMENTATION 


Object ives 

The  ETRs  feed  three  subsequent  processes.  First,  the  output  from 
the  ETR  analyses  is  used  in  the  ET  design  process where  the  form 
and  content  of  ET  are  structured.  Second,  the  ETRs  have  strong 
implications  for  early  hardware  and  software  decisions  that  are  part  of 
the  design  process^  for  the  prime  equipment  in  which  training  is  to 
be  embedded.  Third,  courseware  and  training  development  processes  will 
use  the  database  developed  in  identifying  ETRs  to  develop  the  training. 
The  purpose  of  this  section  is  to  structure  the  outputs  from  the  ETR 
process  so  that  they  are  maximally  useful  to  support  these  processes. 
While  this  section  does  not  prescribe  exact  procedures  for  generating 
outputs,  a  general  structure  is  provided.  This  structure  is  reflected 
in  Figure  6. 


Rat ionale 

The  final  database  resulting  from  the  ETR  analyses  contains  a 
large  amount  of  data;  in  the  next  subsection  17  different  data  elements 
are  listed.  These  data  elements  are  either  descriptions  or  multiple 
logical  entries.  The  most  useful  way  to  present  most  of  this  informa¬ 
tion  is  on  a  task-by-task  basis.  If  one  were  to  create  a  listing  that 
has  several  columns,  the  information  about  each  objective  might  be  seen 
side-by-side.  The  sheer  amount  and  number  of  different  data  items 
pertinent  to  an  objective  make  the  concurrent  presentation  of  all  of 
the  data  items  impossible.  It  is  necessary  to  break  this  information 
down  into  coherent  smaller  reports  so  tnat  each  user  sees  relevant 
information  quickly,  and  can  perform  rapid  analyses  of  the  data  to 
facilitate  decision  making. 

The  purpose  of  this  section  is  to  specify  formats  for  a  set  of 
data  reports  that  present  this  information  to  different  users,  in  a 


^See:  Implementing  Embedded  Training  (ET):  Volume  5  of  10: 

Designing  the  ET  Component 

^See :  Implementing  Embedded  Training  (ET):  Volume  6  of  10: 

Integrating  ET  with  the  Prime  System 
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Final 

Database 


ETRs  - 
Listings  and 
Summaries 


End 

PHASE  FOUR 


Figure  6.  Overview  of  procedures  to  prepare  ET  requirement 
doc  ument  a  1 1  on . 
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usable  way.  Some  of  the  information  is  presented  more  than  once, 
because  different  processes  require  both  common  information  and  unique 
in  format  ion . 


Procedure 


Data  items  in  each  objective  record  come  from  the  analyses 
performed  in  Phases  One  through  Three.  The  data  to  be  formatted  and 
organized  are  in  3  categories:  (1)  task  analysis  data,  (2)  ET 
development  data,  and  (3)  audit  trail  data. 


Data  Elements  to  be  Reported 

Objective  analysis  data  are: 

1.  Task  or  objective  number  generated  during  analysis  (also 
mission  and  phase  numbers). 

2.  Task  or  objective  statement  (also  mission  and  phase 
titles) . 

3.  Conditions  of  performance. 

4.  Standards  of  performance. 

5.  Common  phase  and  task  or  objective  numbers. 

6.  Crew  positions  involved  in  the  performance  of  the  task. 

ET  development  data  are: 

1.  Objectives  classification  (and  certainty  codes,  if 
assigned) . 

2.  Task  or  objective  perishability  rating. 

3.  Task  or  objective  criticality  rating  (and  certainty  codes, 
i f  assigned )  . 

4.  ET  nomination. 

5.  Implementation  approach  for  objective  within  ET. 

Audit  trail  data  are: 

1.  Source  of  task  or  objective  description  information. 

2,  Page  reference  within  the  information  source. 


Content  of  Data  Elements 


The  above  data  elements  are  explained  here.  Justification  of  the 
content  and  examples  of  the  data  elements  are  included  as  appropriate. 

Task  or  Objective  Number.  This  is  assigned  to  the  task  or  objec¬ 
tive  by  the  analysis  team.  The  numbering  system  is  hierarchical; 
longer  numbers  represent  lower-order  tasks  or  objectives  that  enable 
the  performance  of  higher-order  task  or  objectives.  A  convenient 
approach  is  to  use  two  digit  numbers  to  represent  mission  phases  (or 
other  functional  break-outs)  (e.g.,  02,  Mission  Preparation  phase),  two 
additional  digits  separated  from  the  phase  digits  by  periods  to 
represent  tasks  (e.g.,  02.06,  Load  Ammunition),  two  mere  digits  to 
represent  subtasks,  and  so  forth  for  finer  subdivisions,  with  each  two 
digits  separated  from  the  previous  pair  by  a  period.  Each  lower-order 
subtask  is  required  for  the  proper  performance  of  the  higher-order 
element . 

Task  Statement.  This  is  a  title  or  description  of  the  task  or 
objective.  The  wording  of  the  task  or  objective  descriptions  should  be 
chosen  carefully.  Each  description  of  a  task,  subtask,  etc.  should  be 
able  to  stand  alone.  That  is,  if  the  description  were  to  be  written 
outside  the  context  of  the  task  or  objective  elements  above  and  below 
it,  the  reader  should  understand  it.  For  example. 

Incorrect 


02.06.01 

02.06.01.01 

02.06.01.02 


Perform  a  receipt  inspection  on  the 
projectile . 

Un package . 

Inspect. 


Correct 

02.06.01  Perform  a  receipt  inspection  on  the 
projectile. 

02.06.01.01  Unpackage  the  projectile. 

02.06.01.02  Inspect  the  projectile. 

Conditions  of  Performance.  These  are  the  circumstances  under 
which  the  task  is  performed  as  identified  in  Phases  One  and  Two. 

Standards  of  Performance.  This  is  how  well  an  action  must  be 
performed.  For  the  ETR,  this  state-ent  only  specifies  the  measure  or 
dimension  of  performance  measurement  (e.g.,  speed  of  trigger  pull, 
distance  from  target),  and  not  the  actual  values. 
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Common  Task  or  Objective  Numbers.  Some  activities  are  called  for 
more  than  once  in  an  objectives  hierarchy.  For  instance,  "Prepare  for 
firing"  might  appear  under  both  manual  and  automatic  firing  objec¬ 
tives.  All  the  numbers  that  refer  to  the  same  activity  are  common 
task/objective  numbers. 

Crew  Position.  These  are  tue  crew  positions  that  are  involved  in 
the  performance  of  the  particular  task,  and  are  the  targets  of 
training.  A  task  or  objective  that  has  lower-level  subtasks  includes 
the  crew  positions  that  are  involved  in  the  subtasks.  Note  that  entry 
of  multiple  crew  positions  indicates  that  there  may  be  a  need  to 
provide  team  training  or  coordinated  training  for  the  crew  positions 
involved. 

Objectives  Clcs -ixication.  This  is  the  classification  of  the 
objective  into  one  cf  seven  types,  performed  during  Phase  Three.  This 
information  is  used  in  the  rating  of  perishability,  and  is  described  in 
Section  4.  If  certainty  codes  were  assigned,  they  also  appear  here. 

Perishability  Rating.  Perishability  is  defined  as  the  likelihood 
that  task  performance  will  suffer  if  the  task  is  not  practiced.  This 
rating  can  take  values  of  low,  medium,  or  high.  Task  perishability  is 
inferred  from  the  objective  classification,  which  is  performed  in  Phase 
Three.  A  procedure  to  generate  task  perishability  ratings  is  found  in 
Section  4.  Certainty  codes,  if  assigned,  also  appear  in  this  field  of 
data . 


Criticality  Rating.  Criticality  is  defined  as  the  likelihood  that 
a  given  task  may  result  in  mission  failure,  personal  injury,  or  damage 
to  equipment.  This  rating  can  take  values  of  low,  medium,  or  high. 
Criticality  ratings  are  performed  in  Phase  Three,  and  the 
classification  scheme  is  presented  in  Section  4. 

ET  Nomination.  This  nomination  is  a  product  of  the  ET  decision 
model  that  is  applied  in  Phase  Three.  There  will  be  a  nomination  of 
the  suitability  for  ET  for  each  objective. 

Implementation  Feasibility  Code.  This  is  the  code  assigned  during 
assessment  of  the  implementation  potential  of  each  ET-nominated  objec¬ 
tive,  in  Phase  Three.  Codes  which  will  appear  in  this  data  field  are 
described  in  Section  4. 

Source  of  Information.  This  is  a  statement  of  where  the  informa¬ 
tion  for  the  task  or  objective  description  or  other  data  were  obtained. 
As  the  taste  or  objective  analysis  is  developed  to  the  appropriate  level 
of  detail  it  sometimes  becomes  unclear  where  the  information  about  a 
task  or  objective  or  subtask  came  from.  Sources  of  data  include 
original  task  listings,  Plans  of  Instruction  (POIs),  training  manuals, 
engineering  data,  system  development  briefings,  SME  inputs,  and  so 
forth.  A  training  feature  may  be  developed  to  serve  a  particular 
training  need,  and  questions  may  arise  about  the  substance  of  this 
task.  The  source  of  information  pinpoints  the  exact  wording  of 
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original  task  or  objective  information  and  also  helps  in  evaluating  the 
currency  of  the  information  source.  Document  numbers  should  be 
included.  This  field  should  be  initially  used  when  source  information 
is  first  identified  and  used  in  task  identification.  The  field  should 
be  expanded  or  updated  if  new  information  is  gathered  or  discovered. 

Page  or  Reference  Number.  Information  about  where  in  the  source 
the  information  was  found  speeds  checking  of  the  original  source 
documentation. 

Military  Service  Task  or  Objective  Number.  If  the  original  source 
or  information  for  this  task  or  objective  was  a  military  task  or  objec¬ 
tive  listing,  then  there  is  a  task  or  objective  number  already  assigned 
to  the  task.  This  number  should  be  included  in  the  audit  trail  data, 
even  if  subsequent  editing  results  in  minor  word  changes.  Note  that 
this  is  only  the  administratively-accepted  task  number  which  corres¬ 
ponds  to  an  identified  task.  The  "working"  task  number  (see  Phase  Two 
and  Appendix  C)  is  used  for  analysis.  The  number  in  this  field  is 
included  to  provide  a  cross-reference  to  official  documentation  which 
may  have  been  used  as  source  material. 


Products 


Reports  are  relatively  easy  to  generate  if  the  data  collection  has 
made  use  of  a  computer-based  DBMS,  because  these  systems  usually  have 
built-in  report  generators  that  can  structure  the  data  output  to  fit 
the  formats  described. 

The  above  data  elements  could  be  reported  in  one  large  printout, 
but  this  would  require  that  they  be  listed  sequentially  for  each 
objective.  This  approach  is  not  amenable  to  rapid  overview  and  quick 
consultation  for  analytic  and  decision  making  purposes. 

An  approach  that  is  better  suited  to  further  analysis  is  to 
present  the  data  in  matrix  form,  with  each  objective  occupying  a  row  in 
the  matrix,  and  with  the  proper  data  elements  in  columns.  Using  this 
approach,  there  is  too  much  information  for  either  dimension,  rows  or 
columns,  to  fit  on  a  page.  The  solution  is  to  generate  separate 
reports  that  include  the  data  required  for  the  purposes  of  each  report. 
This  approach  is  taken  for  all  but  the  first  report,  which  is  an  objec¬ 
tive  analysis  reference  document.  An  example  of  such  a  report  format 
is  shown  in  Figure  7. 

There  are  two  data  elements  that  are  common  to  all  reports:  task 
or  objective  number  and  task  or  objective  statement.  It  is  difficult 
to  make  sense  out  of  a  report  without  the  description,  and  the  number 
provides  a  unique  reference.  Reports  are  designed  so  that  they  can 
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Task  Number 

Task  Description 

Crew 

PR 

CR 

ET 

Train 

Level 

03 

MOVEMENT 

CS,D 

M 

H 

A,  S,F 

03.01 

Move  to  the  Initialization  Survey  Point  (ISP) 

CS,D 

L 

M 

Y 

A 

03.01.01 

Drive  the  SPH 

D 

L 

M 

N 

A 

03.01.01.02 

Press  and  hold  the  brake  pedal 

D 

L 

M 

N 

A 

03.01.01.03 

Release  the  handbrake 

D 

L 

M 

N 

A 

03.01.01.04 

Shift  Into  1st  gear 

D 

L 

M 

N 

A 

03.01.01.05 

Release  the  brake  pedal 

D 

L 

M 

N 

A 

03.01.01.06 

Press  the  accelerator  pedal 

D 

L 

M 

N 

A 

03.01.01.07 

Shift  the  transmission  gears  as  required 

D 

L 

M 

N 

A 

03.01.01.08 

Steer  the  vehicle  as  required 

D 

L 

M 

N 

A 

03.01.01.09 

Respond  to  the  orders  from  the  chief  of  section 

D 

L 

M 

N 

A 

03.01.01.10 

Perform  the  During  (D)  Preventive  Maintenance  Checks  and 
Services  (PMCS) 

D 

l 

M 

N 

A 

03.01.01.11 

Maneuver  the  SPH  so  the  left  sprocket  is  next  to  the 
survey  point 

CS.D 

L 

M 

N 

A 

03.01.01.12 

Use  visual  signals  to  control  movement  (mounted) 

CS 

L 

M 

N 

A 

Figure  7.  Example  report  form. 
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easily  be  printed  and  published.  All  but  the  first  report  are  of  a 
size  that  can  be  printed  across  wide  paper  (130  columns),  which  can  be 
bound  sideways  in  a  report;  the  first  is  standard  width  (75  columns). 


Report  1 — Task  or  Objective  Analysis  Overview 

This  report  contains  the  basic  task  or  objective  analysis  informa¬ 
tion.  Its  data  elements  are:  task  or  objective  number,  task  or  objec¬ 
tive  statement,  crew  positions,  conditions  of  performance,  standards  of 
performance,  and  common  task  or  objective  numbers.  Each  data  element 
is  listed  sequentially  as  a  separate  row,  unlike  the  other  reports. 

This  report  is  sorted  or  indexed  by  task  or  objective  number.  This 
information  is  useful  during  efforts  aimed  at  producing  courseware  or 
generating  a  final  task  analysis. 


Report  2 — ET  Nominations 

This  report  is  printed  in  130  columns  and  contains:  task  or 
objective  number,  task  or  objective  statement,  crew  positions,  objec¬ 
tives  classification,  perishability  rating,  criticality  rating,  ET 
nomination,  and  implementation  approach.  The  purpose  of  this  report  is 
to  be  able  to  look  at  all  tasks  and  see  which  ones  are  nominees  for  ET 
along  with  the  data  supporting  this  nomination.  This  report  is  sorted 
or  indexed  by  task  or  objective  number. 


Report  3 — ET  Nominations  and  Implementation  Judgments 

This  report  is  printed  in  130  columns  and  contains:  task  or 
objective  number,  task  or  objective  statement,  ET  nomination,  and 
implementation  approach.  It  is  useful  to  present  this  report  indexed 
by  task  or  objective  number. 


Report  3A — Crew  Position  Breakdown 

This  is  a  series  of  ET  nomination  and  implementation  judgment 
reports,  one  for  each  crew  position.  Only  the  data  pertaining  to  the 
individual  crew  position  should  be  included  in  each  report.  This 
report  is  of  use  when  revising  prior  training  and  training  guidance 
material  already  organized  by  crew  position.  These  reports  also 
provide  a  clear  picture  of  how  many  ET-r.rminated  objectives  and  tasks 
pertain  to  each  crew  position. 


Report  3B — ET  Task  or  Objective  Listing 

This  is  an  optional  report  that  presents  the  data  of  Report  3,  but 
only  for  those  tasks  for  which  ET  is  nominated.  The  ET  nomination 
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column  is  deleted.  If  the  full  task  listing  is  quite  large,  then  this 
listing  is  useful  in  reviewing  ET  and  determining  requirements  for 
implementation. 


Report  4 — Audit  Trail 

This  report  is  printed  in  130  columns  and  contains:  task  or 
objective  number,  task  or  objective  statement,  source  of  information 
for  the  task  or  objective  statement,  page  reference  within  the 
information  source,  and  military  service  task  or  objective  number  (if 
applicable) . 


Report  5 — Common  Task  or  Objective  Numbers 

This  report  is  printed  in  130  columns  and  contains:  task  or 
objective  number,  task  or  objective  statement,  and  common  task  or 
objective  numbers.  The  common  task  or  objective  numbers  are  often 
quite  long,  and  this  mode  of  presentation  simplifies  looking  them  up 
when  creating  courseware. 
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APPENDIX  A 

WEAPON  SYSTEM  OPERATIONAL  MISSION  MODEL 


A- 1 


This  Appendix  presents  a  generic  mission  model  that  can  be  applied 
to  some  types  of  weapon  systems  daring  the  task  analysis.  The  model 
aids  analysts  in  structuring  the  tasks  into  a  hierarchical  form.  This 
model  is  suitable  only  for  ground-based  weapon  systems  and  their 
operational  missions.  The  model  uses  the  following  phases  to  describe 
the  operational  mission: 

1.  Planning 

2.  Preparation 

3.  Movement 

4.  Deployment 

3.  Operation 

6.  Replenishment/Resupply 

7.  Post-Mission 

The  first  two  phases  normally  occur  once  during  a  mission.  Phases 
three,  four,  five,  and  six  can  occur  numerous  times  and  in  different 
order  during  a  mission.  The  final  phase  normally  occurs  once,  at  the 
end  of  the  mission.  Figure  A-l  presents  these  phases  in  hierarchical 
form. 


Planning  Phase.  Crews  perform  some  planning  tasks  which  are 
normally  covered  by  doctrine  in  the  form  of  Standard  Operating  Proce¬ 
dures  (SOP).  These  tasks  are  often  performed  at  a  briefing  site  and 
result  in  a  briefing  to  disseminate  mission  information. 

Preparation  Phase.  Tasks  associated  with  weapon  system  initiali¬ 
zation,  Preventive  Maintenance  Checks  and  Services  (PMCS),  communica¬ 
tions  checks,  and  operator  maintenance. 

Movement  Phase.  Transporting  and  navigating  the  weapon  system. 

It  includes  movement  to,  within,  and  from  the  deployment  site. 
Contingencies  such  as  navigational  system  failure  are  important  during 
this  phase. 

Deployment  Phase.  Emplacement,  camouflage,  and  defense  posture  of 
the  weapon  system.  It  may  include  initialization  procedures  for  weapon 
subsystems  secured  during  movement . 

Operation  Phase.  Operating  the  weapon  system  and  engaging  the 
enemy.  In  sensor  driven  weapon  systems,  this  phase  is  divided  into 
search,  detect,  track,  acquire,  identify  and  classify,  engage,  and 
assess  engagement.  Other  aspects  of  this  phase  may  include:  operating 
communications  equipment;  performing  unusual  operations,  such  as 
fire-fighting  or  NBC  warfare;  and  contingencies,  such  as  response  to 
weapon  system  equipment  failures  and  response  to  tactical  changes. 
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Replenishment  or  Resupply  Phase.  Resupplying  ammunition,  fuel, 
and  other  commodities  needed  by  the  weapon  system.  This  phase  may 
include  requesting  a  resupply  mission  and  coordinating  a  rendezvous 
with  a  resupply  vehicle. 

Post-Mission  Phase.  Weapon  system  shutdown,  clean-up,  and 
post-mission  preventive  maintenance  checks  and  services,  and  mission 
debrief.  Most  of  the  tasks  in  this  phase  are  procedures. 
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APPENDIX  B 

TASK  OR  OBJECTIVE  ACTION  VERBS 
AND  THEIR  DEFINITIONS 
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INTRODUCTION 


This  Appendix  lists  action  verbs  that  may  be  used  in  a  task  or 
objective  title  and  its  definition.  Some  specialized  verbs,  not  listed 
here,  may  be  needed  for  particular  weapon  systems.  For  example,  "lay" 
is  commonly  used  in  task  or  objective  titles  for  cannon-type  weapon 
systems,  but  is  not  applicable  to  all  weapon  systems.  Verbs  for 
operator  maintenance  tasks  or  objectives  are  included  in  this  listing. 
Many  of  the  verbs  presented  here  are  synonymous.  The  analysts  should 
select  the  one  verb  which  appears  to  be  best  and  use  it  consistently 
throughout  the  analysis. 

This  verb  list  is  an  expanded  version  of  the  action  verb  list 
contained  in  Air  Force  Pamphlet  50-58,  Instructional  Systems 
Development .  Expansions  were  derived  because  of  a  need  to  include 
verbs  associated  with  primarily  cognitive-type  tasks,  that  did  not 
appear  in  the  original  listing. 
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Access 


1.  To  gain  visibility  of  or  the  ability  to  manipulate. 

2.  To  cause  to  be  displayed,  as  with  a  computer  menu. 


Accomplish 

Achieve 

Acknowledge 

Actuate 

Adjust 

Administer 

Advance 

Advise 

Alert 

Align 

Allocate 

Allow 

Analyze 

Annotate 

Announce 

Apply 


To  do,  carry  out,  or  bring  about;  to  reach  an 
objective. 

To  carry  out  successfully. 

To  make  known  the  receipt  or  existence  of. 

To  put  into  mechanical  motion  or  action;  to  move  to 
action. 

1.  To  bring  to  a  specified  position  or  state. 

2.  To  bring  to  a  more  satisfactory  state;  to  manipulate 
controls,  levers,  linkages,  etc.;  to  return 
equipment  from  an  out-of-tolerance  condition  to  an 
in-tolerance  condition. 

To  manage  or  supervise  the  execution,  use,  or  conduct 
of . 

To  move  forward;  to  move  ahead. 

To  give  information  or  notice  to. 

To  warn;  to  call  to  a  state  of  readiness  or 
watchfulness;  to  notify  (a  Person)  of  an  impending 
action. 

To  bring  into  line;  to  line  up;  to  bring  into  precise 
adjustment,  correct  relative  position;  or  coincidence. 

To  apportion  for  a  specific  purpose  or  to  particular 
persons  or  things. 

1.  To  permit;  to  give  opportunity  to. 

2.  To  allot  or  provide  for. 

3.  To  carry  out  a  procedure. 

To  examine  and  interpret  information. 

To  append  explanatory  information  to  a  text  or  graphic 
summary  of  information. 

To  make  known. 

1.  To  lay  or  spread  on. 

2.  To  energize. 
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Archive 


To  make  an  archival  copy  of. 


Arrange 

To  group  according  to  quality,  value,  or  other 
characteristics;  to  put  in  proper  order. 

Assemble 

To 

or 

fit  and  secure  together  the  several  parts  of;  to  make 
form  by  combining  parts. 

Assess 

To  determine  the  importance,  size,  or  value  of;  to 
evaluate . 

Assign 

To  apportion  to  for  a  specific  purpose  or  to  particular 
persons  or  things;  to  appoint  to  a  duty. 

Assist 

To 

give  support  or  help;  to  aid. 

Attach 

To 

join  or  fasten  to. 

Authenticate 

To 

prove  or  serve  to  prove  the  authenticity  of. 

Balance 

To 

equalize  in  weight,  height,  number,  or  proportion. 

Brief 

To 

in 

give  final  precise  instructions;  to  coach  thoroughly 
advance;  tc  give  essential  information  to. 

Calculate 

To 

determine  by  arithmetic  processes. 

Calibrate 

To  determine  accuracy,  deviation,  or  variation  by 
special  measurement  or  by  comparison  with  a  standard. 

Catnouf  lage 

To 

conceal  or  disguise  by  camouflage. 

Cancel 

To 

cause  not  to  occur,  as  in  cancelling  a  command. 

Categorize 

To 

put  into  categories  or  general  classes. 

Center 

1. 

To  adjust  so  that  axes  coincide. 

2. 

To  place  in  the  middle  of. 

Change 

1. 

To  replace  with  another  comparable  item  or 
information  entity. 

2. 

To  adjust. 

Check 

1. 

To  confirm  or  establish  that  a  proper  condition 

exists;  to  ascertain  that  a  given  operation  produces 
a  specified  result;  to  examine  for  satisfactory 
accuracy,  safety,  or  performance;  to  confirm  or 


determine  measurements  by  use  of  visual  or 
mechanical  means. 

2.  To  perform  a  critical  visual  observation  or  check 
for  specific  conditions;  to  test  the  condition  of. 

Chock  To  place  a  blocking  device  adjacent  to,  in  front  of,  and 

behind  a  wheel  to  keep  from  moving. 

Choke  To  enrich  the  fuel  mixture  of  a  motor  by  partially 

shutting  off  the  air  intake  of  the  carburetor. 

Choose  To  select  after  consideration. 

Chunk  To  cause  the  association  of  several  entities. 

Classify  To  put  into  categories  or  general  classes. 

Clean  To  wash,  scrub,  or  apply  solvents  to;  remove  dirt, 

corrosion,  or  grease. 

Clear  1.  To  move  people  and/or  objects  away  from. 

2.  To  open  the  throttle  of  an  idling  engine  to  free  it 
from  carbon. 

Close  1.  To  block  against  entry  or  passage;  to  turn,  push,  or 

pull  in  the  direction  in  which  flow  is  impeded. 

2.  To  set  a  circuit  breaker  into  the  position  allowing 
current  to  flow  through. 

Collect  To  bring  together  into  one  body  or  place;  to 

accumulate . 

Command  To  direct  authoritatively. 

Communicate  1.  To  exchange  information. 

2.  To  make  known. 

Compare  To  examine  the  character  or  qualities  of  two  or  more 

items;  to  discover  resemblances  or  differences. 

Complete  1.  To  bring  to  an  end. 

2.  To  supply  missing  or  needed  information,  normally  in 
a  prescribed  format. 

Comply  To  conform  with  directions  or  rules;  to  accept  as 

authority;  to  obey. 
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Compute 


To  determine  by  arithmetic  processes. 


Condense 

Connect 

Construe  t 

Control 

Coordinate 

Correct 

Correlate 

Cover 

Create 

Decide 

Deenergize 

Define 

Def late 
Delete 

Deliver 

Demonstrate 

Depart 


To  make  denser,  more  brief,  or  more  compact. 

1.  To  bring  or  fit  together  so  as  to  form  a  unit,  to 
couple  keyed  or  matched  equipment  items. 

2.  To  attach  or  mate  (an  electrical  device)  to  a 
service  outlet. 

1.  To  make  or  farm  by  combining  parts;  to  nt  ana 
secure  together  the  several  parts  of. 

2.  To  assemble  information  elements  or  entities  in  a 
specified  fashion. 

To  exercise  restraining  or  directing  influence  over;  to 
fix  or  adjust  the  time,  amount,  or  rate  of. 

To  bring  into  a  common  action,  movement,  or  condition. 

To  make  or  set  right,  to  alter  or  adjust  so  as  to  bring 
to  some  standard  or  required  condition. 

To  establish  a  mutual  or  reciprocal  relation  between. 

To  protect  or  shelter  by  placing  something  over  or 
around. 

To  cause  to  come  into  being,  normally  based  on  some 
established  criterion. 

To  arrive  at  a  solution. 

To  take  energy  from. 

1.  To  determine  or  identify  the  essential  qualities  or 
meaning. 

2.  To  fix  or  mark  the  limits  of. 

To  release  air  or  gas  from. 

To  remove  from  association  with  or  cause  to  no  longer 
exist . 

1.  To  hand  over. 

2.  To  send  to  an  intended  target  or  destination. 

To  show  clearly. 

To  go  away;  to  leave. 
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Depressurize  To  release  gas  or  fluid  pressure  from. 

Derive  To  infer  or  deduce. 

Describe  To  represent  or  give  an  account  of  in  words. 

Destroy  To  ruin,  demolish,  or  put  out  of  existence;  to  make 

unfit  for  further  use. 

Detect  To  discover  or  determine  the  existence,  presence,  or 

fact  of. 

Determine  1.  To  obtain  definite  and  first-hand  knowledge  of,  to 

confirm,  or  establish  that  a  proper  condition 
exists . 

2.  To  investigate  and  decide  to  discover  by  study  or 
experiment . 

Develop  To  set  forth  or  make  clear  by  degrees  or  in  detail. 

Diagnose  To  recognize  and  identify  the  cause  or  nature  of  a 

condition,  situation,  or  problem  by  examination  or 
analysis . 

Disassemble  To  take  to  pieces;  to  take  apart  to  the  level  of  the 
next  smaller  unit  or  down  to  all  removable  parts. 

Disconnect  1.  To  sever  the  connection  between;  to  separate  keyed 

or  matched  equipment  parts. 

2.  To  detach  or  separate  (an  electrical  device)  from  a 
service  outlet. 

Discriminate  To  distinguish  or  differentiate  by  discerning  or 
exposing  differences. 

Disengage  To  release  or  detach  interlocking  parts;  to  unfasten;  to 

set  free  from  an  inactive  or  fixed  position. 

Display  To  cause  a  visual  image  to  be  presented  on  some  medium. 

Dispose  of  To  get  rid  of. 

Distinguish  To  perceive  a  difference  in. 

Distribute  1.  To  apportion  for  a  specific  purpose  or  to  particular 

persons  or  things. 

2.  To  divide  among  several  or  many;  to  divide  or 
separate,  especially  into  kinds. 


Drain 

Draw 

Drive 

Edit 

Egress 

Elaborate 

Elevate 

Eliminate 

Emplace 

Employ 

Energize 
Enf  orce 
Engage 

Enter 

Erect 

Establish 

Estimate 

Evaluate 

Exchange 

Execute 

Explain 


To  draw  off  (liquid)  gradually  or  completely. 

To  produce  a  likeness  or  representation  of. 

To  direct  the  course  and  motions  of  a  vehicle. 

To  correct  errors  of  grammar,  syntax,  and  content  in 
text  material. 

To  go  out. 

To  provide  more  detail  regarding. 

To  lift  up;  to  raise. 

To  expel;  to  ignore  or  set  aside  as  unimportant. 

To  put  into  position. 

To  put  into  action  or  service;  to  carry  out  a  purpose  or 
action  by  means  of;  to  avail  oneself  of. 

To  impart  energy  to. 

To  compel  or  constrain. 

1.  To  cause  to  interlock  or  mesh. 

2.  To  enter  into  conflict. 

1.  To  go  or  come  in. 

2.  To  put  on  record. 

3.  To  put  in  information  or  data. 

To  put  up  by  the  fitting  together. 

To  set  on  a  firm  basis. 

To  judge  or  determine  roughly  the  size,  extent,  or 
nature  of. 

To  determine  the  importance,  size,  or  nature  of;  to 

appraise;  to  give  a  value  or  appraisal  to  on  the  basis 

of  collected  data. 

To  part  with  or  substitute. 

To  carry  out  fully. 

To  make  something  plain  and  understandable. 
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Express 
Extract 
Fill  out 
Find 

Fire 

Hold 

Hypot  hesize 

Identify 

Illustrate 

Indicate 

Inform 

Initialize 

Input 

Insert 

Inspect 

Install 

Instruct 


To  represent  in  words;  to  state. 

To  draw  forth;  to  pull  out  forcibly. 

To  enter  information  on  a  form. 

1.  To  discover  or  determine  by  search;  to  indicate  the 
place,  site,  or  limits  of. 

2.  To  discover  by  study  or  experiment;  to  investigate 
and  decide. 

To  launch  a  missile  or  shoot  a  gun. 

To  have  or  keep  in  the  grasp. 

To  develop  a  prediction  or  speculation,  of  some  degree 
of  uncertainty,  based  on  incomplete  factual  information 
or  theory. 

1.  To  establish  the  identity  of. 

2.  To  determine  the  classification  of. 

To  make  clear  or  clarify. 

To  point  out. 

To  make  known  to;  to  give  notice  or  report  the 
occurrence  of. 

To  place  in  an  initial  or  beginning  condition. 

To  enter  information  into  a  computer  or  data  system. 

To  put  or  thrust  in,  into,  or  through. 

To  perform  a  critical  visual  observation  or  check  for 
specific  conditions;  to  test  the  condition  of. 

1.  To  perform  operations  necessary  to  properly  fit  an 
equipment  unit  into  the  next  larger  assembly  or 
system. 

2.  To  place  and  attach. 

To  provide  with  authoritative  information  or  advice. 

To  bring  together  information  from  two  or  more  different 
sources  for  the  purpose  of  combined  analysis  or 
presentation. 


Integrate 


Intercept 


To  stop  or  interrupt  the  progress  or  course  of. 


Interpret  1.  To  conceive  in  the  light  of  individual  belief, 

judgment,  or  circumstance. 

2.  To  explain  the  meaning  of. 

Investigate  To  observe  or  study  by  close  examination  and  systematic 
inquiry. 

Isolate  To  use  test  equipment  to  identify  or  select  a  source  of 

trouble. 


Issue  To  put  forth  or  distribute. 

Lift  To  move  or  cause  to  be  moved  from  a  lower  to  a  higher 

position;  to  elevate. 


List 

To 

enumerate;  to  place  a  group  of  items  together. 

Listen 

To 

hear  something  with  thoughtful  attention. 

Load 

To 

on 

place  in  or  on;  to  place  cargo  or  aircraft  components 
an  airplane  or  other  vehicle. 

Locate 

1. 

To  find,  determine,  or  indicate  the  place,  site,  or 
limits  of. 

2. 

To  set  or  establish  in  a  particular  spot;  to 
station. 

Log 

1. 

To  record  for  purposes  of  keeping  records. 

2. 

To  gain  access  to  a  computer  system  or  terminate 
interaction  with  a  computer  system. 

Lubricate  To  put  lubricant  on  specified  locations. 


Maintain  1.  To  hold  or  keep  in  any  particular  state  or 

condition,  especially  in  a  state  of  efficiency  or 
validity. 

2.  To  sustain  or  keep  up. 

Manage  To  handle  or  direct  with  a  degree  of  skill. 

Maneuver  To  make  a  series  of  changes  in  direction  and  position 

for  a  specified  purpose. 

Manipulate  To  operate  with  the  hands. 

Measuie  To  determine  the  dimensions,  capacity,  or  amount  by  use 

of  standard  instruments  or  utensils. 
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Modify 


To  alter  or  change  somewhat  the  form  or  qualities  of. 


Monitor 

Mount 

Move 

Name 

Navigate 

Neutralize 

Notify 

Observe 

Obtain 

Open 


Operate 

Organize 

Orient 

Originate 


1.  To  visually  take  note  of  or  to  pay  attention  to  in 
order  to  check  on  action  or  change. 

2.  To  continually  or  periodically  attend  to  displays  to 
determine  equipment  condition  or  operating  status. 

To  attach  to  a  support. 

To  change  the  location  or  position  of. 

To  identify  by  name. 

To  operate  and  control  course  of. 

To  destroy  the  effectiveness  of;  to  nullify. 

To  make  known  to;  to  give  notice  or  report  the 
occurrence  of. 

1.  To  conform  one's  actions  or  practice  to. 

2.  To  visually  take  note  of;  to  pay  attention  to. 

1.  To  get  or  find  out  by  observation  or  special 
procedures . 

2.  To  gain  or  attain. 

1.  To  move  from  closed  position;  to  make  available  for 
passage  by  turning  in  an  appropriate  direction. 

2.  To  make  available  for  entry  or  passage  by  turning 
back,  removing,  or  clearing  away. 

3.  To  disengage  or  pull  out  a  circuit  breaker. 

To  control  equipment  in  order  to  accomplish  a  specific 
purpose . 

To  arrange  elements  into  a  whole  of  interdependent 
parts;  to  form  into  a  coherent  unity;  to  integrate. 

1.  To  acquaint  with  the  existing  situation  or 
environment . 

2.  To  set  or  arrange  in  any  determinate  position. 

To  give  rise  to,  to  set  going,  to  begin. 
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Park 

Perform 

Place 

Plan 

Plot 

Position 
Post 
Prepare 
Presc  ri be 

Press 

Pressurize 

Prevent 

Prioritize 

Process 

Produce 

Program 

Provide 

Pull 

Pump 

Purge 


To  bring  a  vehicle  to  a  stop  and  leave  it  standing  for  a 
time  in  a  specified  area. 

To  do,  carry  out,  or  bring  about;  to  reach  an 
objective . 

To  put  or  set  in  a  desired  location  or  position. 

To  devise  or  project  the  achievement  of. 

To  mark  or  note  on  or  as  if  on  a  map  or  chart;  to  locate 
by  means  of  coordinates. 

To  put  or  set  in  a  given  place. 

To  station  at  a  given  place. 

To  make  ready;  to  arrange  things  in  readiness. 

To  lay  down  as  a  guide,  direction,  or  rule  of  action;  to 
specify  with  authority. 

To  act  upon  through  thrusting  force  exerted  in  contact. 
To  apply  pressure  within  by  filling  with  gas  or  liquid. 
To  keep  from  happening  or  existing. 

To  arrange  or  list  in  order  of  priority  or  importance. 

To  submit  to  a  series  of  actions  or  operations  leading 
to  a  particular  end. 

To  cause  to  come  into  being  or  visibility. 

To  work  out  a  plan  or  procedure  or  a  sequence  of 
operations  to  be  performed. 

To  supply  what  is  needed,  to  equip. 

To  exert  force  upon  an  object  so  as  to  cause  motion 
toward  the  force. 

1.  Raise  or  lower  by  operating  a  device  which  raises, 
transfers,  or  compresses  fluids  by  suction,  pressure 
or  both. 

2.  To  move  up  and  down  or  in  and  out  as  if  with  a  pump 
handle. 

1.  To  expel  unwanted  fluids  from. 

2.  To  cause  to  be  eliminated  or  dissociated  from. 
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Push 


Qualify 

Queue 

Raise 

Read 

Recall 

Receive 

Recognize 

Record 

Recover 

Refuel 

Release 


Remove 


Repair 

Repeat 


1.  To  press  against  with  force  so  as  to  cause  motion 
away  from  the  force. 

2.  To  move  away  or  ahead  by  steady  pressure. 

To  declare  competent  or  adequate. 

To  cause  to  be  placed  in  a  queue  or  ordered  sequence  of 
similar  processes. 

To  move  or  cause  to  be  moved  from  a  lower  to  a  higher 
position;  to  elevate. 

To  derive  information  from  written  material. 

To  bring  forth  information  from  memory. 

To  come  into  possession  of;  to  get. 

To  perceive  to  be  something  previously  known  or 
designated. 

To  set  down  in  writing. 

To  get  back;  to  regain. 

To  put  fuel  into  the  tanks  of  a  vehicle  again. 

1.  To  set  free  from  an  inactive  or  fixed  position;  to 
unfasten  or  detach  interlocking  parts. 

2.  To  let  go  of. 

3.  To  set  free  from  restraint  or  confinement. 

1.  To  perform  operations  necessary  to  take  an  equipment 
unit  out  of  the  next  larger  assembly  or  system. 

2.  To  take  off  or  eliminate. 

3.  To  take  or  move  away. 

4.  To  take  off  devices  for  closing  off  the  end  of  a 
tube . 

To  restore  damaged,  wornout,  or  malfunctioning  equipment 
to  a  serviceable,  usable,  or  operable  condition. 

To  make,  do,  or  perform  again. 
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Replace 


1.  To  restore  to  a  former  place  of  position. 


Report 

Represent 

Request 

Reset 

Resolve 

Respond 

Retrieve 

Review 

Rotate 

Route 

Run 

Save 

Scan 

Schedule 

Search 

Secure 

Select 


2.  To  substitute  serviceable  equipment  for 

malfunctioning,  wornout,  or  damaged  equipment. 

1.  To  describe  as  being  in  a  specified  state. 

2.  To  make  known  to;  to  give  notice  or  report  the 
occurrence  of. 

To  cause  information  to  be  conveyed  in  a  fashion 
different  from  the  original. 

To  ask  for. 

To  put  back  into  a  desired  position,  adjustment,  or 
condition. 

To  eliminate  discrepancies  from  two  or  more  sources  of 
inf  onnation. 

To  react. 

To  cause  to  be  removed  from  storage  or  other  unavailable 
state  and  made  accessible. 

To  examine  again;  to  go  oven  or  examine  critically  or 
deliberately. 

To  cause  to  revolve  about  an  axis  or  center. 

To  send  by  a  selected  course  of  travel;  to  divert  in  a 
specified  direction. 

To  cause  a  computer  program  to  be  executed  by  a 
computer. 

To  cause  to  be  stored  or  placed  in  an  accessible 
location. 

To  make  a  wide,  sweeping  search  of;  to  look  through  or 
over  hastily. 

To  appoint,  assign,  or  designate  for  a  fixed  future 
time;  to  make  a  timetable  of. 

To  examine  a  context  to  determine  the  presence  of  a 
particular  entity  or  type  of  entity. 

To  make  fast  or  safe. 

To  take  by  preference  or  fitness  from  a  number  or  group; 
to  pick  out;  to  choose. 
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Send 

Service 

Set 


Set  up 
Show 

Shut  down 

Sight 

Signal 

Solve 

Specify 

Squeeze 

Start 

State 

Stay 

Steer 


To  dispatch  by  means  of  communication. 

To  perform  such  operations  as  cleanup,  lubrication,  and 
replenishment  to  prepare  for  use. 

1.  To  put  a  switch,  pointer,  or  knob  into  a  given 
position;  to  put  equipment  into  a  given  adjustment, 
condition  a  mode. 

2.  To  put  or  place  in  a  desired  orientation,  condition, 
or  location. 

To  prepare  or  make  ready  for  use. 

To  point  out  or  explain. 

To  perform  operations  necessary  to  cause  equipment  to 
cease  or  suspend  operation. 

1.  To  look  at  through  or  as  if  through  a  sight. 

2.  To  aim  by  means  of  sights. 

To  notify  or  communicate  by  signals  (i.e.,  a  prearranged 
sign,  notice  or  symbol  conveying  a  command,  warning, 
direction  or  other  message). 

To  find  a  solution  for. 

To  name  or  state  explicitly  or  in  detail. 

To  force  or  thrust  together  by  compression. 

To  perform  actions  necessary  to  set  into  operation;  to 
set  going;  to  begin. 

To  express  the  particulars  of  in  words. 

To  remain;  to  continue  in  a  place. 

To  direct  the  course  of. 


Stop 

Store 

Stow 

Strike 


To  perform  actions  necessary  to  cause  equipment  to  cease 
or  suspend  operation. 

To  cause  to  be  placed  in  an  accessible  location. 

To  deposit  or  leave  in  a  specified  place  for  future 
use . 

To  deliver  or  aim  a  blow  or  thrust;  to  hit. 
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Submit 


To  make  available;  to  offer. 


Summarize  To  tell  in  or  reduce  to  a  summary. 

Supervise  To  oversee;  to  have  or  exercise  the  charge  of. 

Synthesize  To  combine  or  produce  by  synthesis. 

Take  1.  To  get  into  or  carry  in  one's  hands  or  one’s 

possession. 

2.  To  get  or  find  out  by  observation  or  special 
procedures . 

Tap  To  strike  lightly. 

Tell  To  express  in  words. 

Test  To  perform  specified  operations  to  verify  operational 

readiness  of  a  component,  subcomponent,  system,  or 
subsystem. 

Tighten  1.  To  perform  necessary  operations  to  fix  more  firmly 

in  place. 

2.  To  apply  a  specified  amount  of  force  to  produce  a 
rotation  or  twisting  motion  to  fix  more  firmly  in 
place. 

Trace  To  follow  or  study  out  in  detail  or  step  by  step. 

Transfer  To  cause  an  entity  to  change  location  or  association 

with  other  entities. 


Transmit 

1. 

To  convey  or  cause  to  pass  from  one 
another. 

place  to 

2. 

To  send  out  a  signal  by  radio  waves 

or  wire. 

Transport 

1. 

To  convey  or  cause  to  pass  from  one 
another. 

place  to 

2. 

To  carry  by  hand  or  in  a  vehicle  or 
container,  etc. 

hoist,  or  in  a 

Traverse 

To 

move  from  side  to  side. 

Troubleshoot 

To 

localize  and  isolate  the  source  of  a 

malfunction  or 

break  down. 


Turn  To  cause  to  revolve  about  an  axis  or  center. 
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Type 


To  enter  information  into  a  device  by  means  of  a 
keyboard. 


Unload 

Update 

Use 

Utilize 

Validate 

Verify 

Visualize 

Wait 

Write 


To  take  off. 

To  replace  older,  possibly  invalid,  information  with 
more  current  information. 

To  pvt  into  action  or  service;  to  avail  oneself  of;  to 
carry  out  a  purpose  or  action  by  means  of. 

To  put  into  action  or  service;  to  avail  oneself  of;  to 
carry  out  a  purpose  or  action  by  means  of. 

To  ascertain  the  correctness  of,  using  an  independent 
source  of  information. 

1.  To  confirm  or  establish  that  a  proper  condition 
exists . 

2.  To  establish  the  truth  or  accuracy  of. 

To  create  a  mental  picture  or  concept  of. 

To  suspend  activity  in  a  sequence  of  activities  until  a 
given  condition  occurs  or  a  given  time  has  elapsed. 

To  inscribe  words  on  a  surface. 


Zero 


To  bring  to  a  desired  level  or  null  position. 
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Introduction 


This  Appendix  discusses  how  to  use  a  Database  Management  System 
(DBMS)  for  ET  requirements  analysis.  Techniques  presented  are 
suggestions,  not  rules.  Use  of  these  guidelines  depends  on  the  DBMS 
and  the  purpose  of  the  analysis.  The  information  is  presented  in  three 
parts.  First  is  the  suggested  structure  of  the  database  for  an  ET 
requirements  analysis,  and  second  are  techniques  and  commands  whicn  cun 
aid  the  analyst  using  a  DBMS.  Following  the  discussion  on  database 
structure  and  DBMS  use,  a  set  of  forms  for  use  in  interim  recording  of 
analysis  products  (before  they  reach  the  database)  is  described,  and 
their  use  in  the  steps  of  the  analysis  process  is  discussed.  It  is 
necessary  to  have  a  basic  knowledge  of  computer  operation  to  use  the 
information  in  this  Appendix. 


Database  Structure 


The  database  structure  is  presented  in  four  categories: 
task/objective  characteristics,  audit  trail  information,  analysis 
information,  and  additional  data  elements  for  future  analyses.  Each 
category  contains  a  list  of  suggested  data  elements  to  include  in  the 
database,  type  of  data  element  or  field  it  represents,  and,  when 
applicable,  the  size  of  the  element. 


Task/Objective  Characteristics 

Title /Descript ion.  This  is  a  short  but  accurate  description, 
beginning  with  an  action  verb,  followed  by  a  proper  noun  and  modifiers. 
There  is  a  title/description  for  each  task  or  objective.  In  the  DBMS, 
this  is  a  character/text  type  data  element  of  at  least  120  character 
length. 

Number.  This  is  the  task  or  objective  number  which  is  unique  for 
each  task  or  objective.  The  numbering  system  can  be  a  sequential 
numbering  system  for  listings  or,  in  the  case  of  a  hierarchy,  a 
numbering  system  indicating  the  level  of  the  task/objective.  The 
numbering  system  suggested  is  double  digits  separated  by  periods.  For 
example,  "01.02.03"  indicates  the  task/objective  is  the  third  subtask, 
in  the  second  task,  of  the  first  phase.  The  example  below  shows  how 
the  numbering  system  indicates  the  task/objective  relationship  with 
other  tasks/objectives  in  the  hierarchy. 

01  Planning  Phase. 

01.01  Collect  weather  information. 
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01.01.01  Communicate  with  weather  center. 

01.01.02  Record  relevant  weather  information. 

01,02  Determine  route  to  combat  area. 

01.02.01  Examine  maps  of  ops  area. 

There  is  a  unique  number  for  each  task/objective .  If  the 
numbering  system  is  sequential,  the  data  element  is  a  character/text 
type  of  at  least  five  characters.  For  task/objective  hierarchies,  the 
data  element  is  character/text  of  at  least  23  characters.  This  is 
equal  to  eight  hierarchical  levels  (i.e.,  01.02.03.04.05.06.07.08). 

Conditions  of  Performance.  There  can  be  numerous  conditions  for 
each  task/objective.  Conditions  are  enumerated  in  a  prioritized  order 
within  this  data  element.  In  the  DBMS,  the  data  element  is  a 
character/text  type  large  enough  to  accommodate  text  descriptions  of 
conditions. 

Standards  of  Performance.  There  can  be  numerous  standards  for 
each  objective.  Standards  are  enumerated  in  a  prioritized  order  within 
this  data  element.  In  the  DBMS,  the  data  element  is  a  character/text 
type  large  enough  to  accommodate  text  descriptions  of  standards. 

Crew  Positions.  With  multi-crew  member  weapon  systems  it  is 
important  to  keep  track  of  which  crew  members  perform  the 
task/objective.  The  analyst  should  include  one  logical  (boolean)  data 
element  for  each  crew  position  to  indicate  whether  the  task/objective 
is  performed  by  that  crew  member.  A  logical  type  data  element  is 
simply  a  Yes/No  or  True/False  indicator.  It  may  be  desirable  to 
include  a  character/ text  data  element  for  recording  the  actual  crew 
position  name.  The  character / text  type  data  element  is  better  for 
printouts  than  the  logical  type,  while  the  logical  type  is  better  for 
database  manipulations  such  as  counts  and  restricted  printouts. 

Common  Numbers.  This  is  a  list  of  the  other  task/objective 
numbers  in  the  hierarchy  which  are  equivalent  to  the  current 
task/objective  description.  A  particular  task  or  objective  may  occur 
numerous  times  in  the  hierarchy.  To  keep  track  of  this,  a 
character/ text  type  data  element  of  a  large  size  contains  the  list  of 
numbers  in  order  of  appearance  in  the  hierarchy.  This  data  element  is 
only  used  for  hierarchies  and  not  for  sequential  listings. 

First  Appearance  Indicator.  This  is  a  logical  type  data  element 
which  indicates  whether  this  is  the  first  occurrence  of  the 
task/objective  in  the  hierarchy.  This  is  only  used  for  hierarchies  and 
not  sequential  listings. 


Audit  Trail  Information 

Source  of  Information.  This  data  element  is  a  record  of  the 
document  or  other  source  from  which  the  task/objective  was  derived.  It 
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may  be  useful  Co  note  the  agency  responsible  for  developing  the 
task/objective.  The  data  element  of  the  DBMS  is  a  character/text  type 
of  at  least  60  characters. 

Page/Reference  Number.  When  the  task/objective  is  derived  from  a 
specific  document,  the  page  number  or  other  relevant  reference  number 
is  recorded  in  this  data  element.  The  data  element  in  the  DBMS  is  a 
character/text  type  of  at  least  15  characters. 

Task/Objective  Developer.  This  data  element  denotes  the  analyst 
or  Subject  Matter  Expert  (SME)  who  developed  a  new  task/objective. 

This  data  element  is  a  character/text  type  of  at  least  10  characters. 
Separate  initials  can  be  separated  by  commas  or  slashes. 

Military  Service  Task/Objective  Number.  This  data  element  is  used 
when  a  task/objective  in  the  developing  hierarchy  is  equivalent  to  a 
task/objective  currently  in  the  military  service.  The  military  task 
number  is  often  found  in  a  POI,  training  guide,  or  soldier's  manual. 

The  data  element  is  a  character/text  type  of  at  least  25  character 
length. 


Analysis  Information 


Criticality  Rating.  This  is  a  character/text  type  data  element  of 
one  character.  The  codes  are  H(igh),  M(edium),  and  L(ow).  There  is  a 
criticality  rating  for  each  task/objective.  If  certainty  codes  are  to 
be  assigned  to  criticality  ratings,  they  also  appear  in  this  field. 

Perishability  Rating.  This  is  a  character/text  type  data  element 
of  one  character.  The  codes  are  H(igh),  M(edium),  and  L(ow).  There  is 
a  perishability  rating  for  each  task/objective. 

ET  Nomination.  This  is  a  logical  type  data  element  which 
indicates  whether  ET  is  suitable  to  train  the  task/objective.  There  is 
one  data  element  for  each  crew  position  in  the  weapon  system  for  each 
task/objective. 

Objectives  Classification.  This  data  element  is  used  when  the 
analysis  is  performed  on  an  objectives  hierarchy.  Each  objective  can 
be  classified  as  one  of  seven  types  of  objectives:  integrated  multiple 
skills,  rule/concept  utilization,  variable/contingency  procedures, 
knowledges,  invariant  procedures,  basic  manipulative  skills,  and  basic 
level  behaviors.  This  classification  is  described  in  Section  4.  If 
certainty  codes  for  objectives  classification  are  used,  they  also 
appear  in  this  field. 

ET  Implementation.  This  data  element  is  the  ET  implementation  and 
feasibility  judgment  code  assigned  in  Step  3.5  of  the  analysis.  This 
is  a  character/text  data  element  one  character  long. 
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Additional  Data  Element  for  Future  Analyses 


Training  Media.  This  data  element  contains  the  media  appropriate 
for  training  the  task/objective.  The  media  can  be  selected  using  a 
media  selection  model.  The  data  element  in  the  DBMS  is  a 
character/ text  type  large  enough  to  accommodate  the  media  names. 

ET  Comments.  This  data  element  describes  the  method  of  training 
the  task/objective  by  ET  envisioned  by  the  analyst  who  nominates  this 
task  for  ET.  For  instance,  if  "Operate  the  radar"  is  the  task, 
"Simulated  radar  targets  and  use  of  actual  radar  controls"  would  be  the 
ET  comment.  This  data  element  is  a  character/text  type  of  at  least  120 
characters . 


A  database  can  be  indexed  or  sorted  on  any  data  element.  The 
difference  between  index  and  sort  is  that  the  index  is  a  logical 
arrangement  of  the  database,  whereas  the  sort  is  a  physical  reordering 
of  the  database  records.  Indexing  is  faster  and  does  not  require 
additional  storage  space.  A  sort  normally  requires  three  times  the 
space  of  the  database  and  if  there  is  not  enough  room  on  the  storage 
device  for  a  sort,  loss  of  data  can  occur. 

Another  application  of  an  index  is  to  organize  the  database  by 
title/description.  This  is  useful  when  identifying  and  standardizing 
common  tasks/objectives  and  finding  the  initial  occurrence  of  the 
task/objective.  This  is  used  during  the  commonality  analyses  (Steps 
1.6  and  1.8). 


The  advantage  to  using  a  character/text  type  data  element  in  a 
database  is  that  it  is  descriptive  and  useful  for  printouts.  The 
logical  type  data  elements  are,  however,  better  for  DBMS  features.  For 
example,  it  is  easier  to  print  out  tasks/objectives  for  a  particular 
weapon  system  operator,  by  searching  for  a  yes/no  indicator  for  that 
operator.  On  the  other  hand,  for  the  printout,  operator  names  may  be 
clearer  than  a  Y  or  N  in  a  column  for  that  operator. 
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Find /Locate  Commands 


Most  DBMSs  have  a  find  or  locate  feature.  This  allows  the  person 
entering  information  or  changing  data  to  access  a  specific  record.  For 
instance,  if  the  DBMS  contains  descriptions  and  numbers  the  next  action 
may  be  to  enter  other  information  for  certain  tasks/objectives.  It  is 
quicker  to  call  the  task/objective  of  interest  than  it  is  to  scroll 
through  the  database  manually. 


Count  Commands 


Some  DBMSs  have  built-in  counting  features.  This  is  useful  during 
analysis  to  assess  the  number  of  times  something  occurs.  For  example, 
if  the  analyst  wants  to  know  how  many  ET  nominated  tasks/objectives 
there  are,  the  DBMS  can  count  faster  than  a  person  with  a  printout. 
Logical  type  data  elements  are  useful  for  counting. 


Replace  Commands 


Some  DBMSs  have  a  replace  feature.  This  allows  the  user  to  enter 
information  automatically  in  a  data  element  for  a  specified  condition. 
For  instance,  if  all  of  the  newest  entries  are  from  the  same  document, 
the  data  entry  person  can  enter  one  letter,  (e.g.,  "X").  After 
entering  all  the  data,  the  user  can  replace  all  occurrences  of  "X"  with 
the  actual  source  document  name. 


Structure  to  Facilitate  Data  Entry 


Generally,  a  task/objectives  hierarchy  is  developed  in  stages. 
First,  the  title/description  is  entered  and  then  numbers  are  assigned. 
The  remainder  of  the  information  is  added  after  these  steps.  To 
facilitate  data  entry,  t^e  data  elements  should  be  ordered  as  they  will 
appear  on  the  data  entry  forms  or  in  the  order  they  will  be  entered. 
Some  DBMSs  allow  the  user  to  modify  the  format  of  the  data  entry 
presentation,  which  simplifies  data  entry.  This  allows  the  user  to 
present  a  screen  for  data  entry  which  looks  like  the  data  entry  form. 


Deleting  Records 

A  task/objective  should  not  be  permanently  deleted  from  the 
database  until  it  is  certain  that  the  task/objective  is  not  needed. 
Some  DBMSs  can  designate  records  as  logically  deleted  rather  than 
physically  erasing  them  from  the  database.  By  using  this  capability, 
tasks/objectives  can  be  screened  out,  without  losing  the  data.  Even 
when  it  is  determined  that  a  task/objective  is  not  needed,  the 
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task/objective  should  be  placed  in  a  separate  file  of  deleted 
tasks/objectives  as  a  safety  measure. 


Report  Generation 

Most  DBMSs  have  an  automatic  report  generator.  Experience  has 
shown  that  it  is  usually  faster  to  use  the  automatic  feature  rather 
than  program  a  customized  report  generating  program.  In  the  case  when 
an  customized  report  is  desired,  it  is  sometimes  possible  to  use  the 
automatic  report  generator  to  create  a  text  file  and  then  use  a  word 
processor  to  customize  it. 


Programming  with  the  DBMS 

Most  DBMSs  have  all  of  the  needed  functions  and  capabilities  built 
into  the  command  language.  It  is  suggested  that  the  casual  DBMS  user 
not  spend  time  writing  programs  using  the  DBMS  programming 
capabilities.  Most  DBMSs  do  not  have  a  full  programming  capability. 
Even  though  it  may  appear  to  be  similar  to  a  known  programming 
language,  it  may  have  its  own  stumbling  blocks. 


Database  Entry,  Interim  Recording  Forms,  and  Data 
Printouts  for  ETR  Analysis 


ETR  analysis  data  are  entered  in  various  stages  during  analysis. 

A  data  entry  form  and  five  printout  formats,  used  during  specific  steps 
of  the  ETR  analysis,  are  presented  to  assist  the  DBMS  user.  Table  C- 1 
shows  the  data  elements  generated  in  the  analyses  and  discussed  in  this 
Appendix  and  the  form  each  is  associated  with. 

The  forms  are  discussed  in  detailed  below.  The  printout  formats 
follow  the  assumption  that  the  printer  used  by  the  DBMS  is  capable  of 
printing  on  wide  paper,  either  11  inches  for  8.5  x  11  inch  paper  or, 
preferably,  11  X  14  inch  paper.  The  paper  can  be  sheet  fed  or  tractor 
fed  (preferable).  It  is  important  to  note  that  all  data  elements  are 
under  continuous  refinement,  even  though  they  may  not  appear  on  a  fora. 
The  printouts  can  be  used  while  the  DBMS  is  on  line  with  the  analyst 
entering  new  data  elements  directly  into  the  database,  or  the  analyst 
can  make  entries  on  the  printout  and  have  clerical  personnel  enter  the 
information  into  the  database  later. 

Form  1  is  used  for  Steps  1.3,  1.4,  1.5,  1.7,  and  2.1  of  the  ETR 
analysis.  This  is  a  data  entry  form  which  has  places  to  record  the 
task/objective  number,  title/description,  conditions  of  performance, 
crew  positions  performing  each  task/objective,  and  audit  trail 
information.  This  form  is  used  for  mission,  mission  phase, 
task/objective,  and  subtask/subob jective  identification.  Once  the  data 
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Table  C-l 


Data  Element  vs.  Data-entry/ printout  Form 
Input/output  forms  for  ETR  Analysis 


Data  Element 

Entry 
Form  1 

Printout 
Form  2 

Printout 
Form  3 

Printout 
Form  4 

Printout 
Form  5 

Printout 
Form  6 

Number 

I 

0 

0 

0 

0 

0 

Title/ Descript  ion 

I 

0 

0 

0 

0 

0 

Condi t ions 

I 

0 

0 

Standards 

I 

0 

Crew  Positions 

I 

0 

0 

0 

0 

Common  Numbers 

I 

First  Appearance 

I 

Source 

I 

Page  No. 

I 

Developer 

I 

0/1 

Mil.  Task.  No. 

I 

Criticality 

I 

0 

0 

Objective  Class. 

I 

0 

0 

Perishability 

A 

0 

0 

ET  Nomination 

A 

0 

0 

Implementing  ET 

I 

0 

I  -  Initial  entry  of  this  data  element. 

0  -  Output  data  element  to  assist  entry  of  other  data  element. 
A  -  Automatically  computed  and  entered  by  the  DBMS  program. 
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is  entered  on  the  form,  clerical  personnel  (or  the  unlucky  analyst)  can 
enter  the  data  into  the  DBMS. 

Form  2  is  used  for  Steps  1.6  and  1.8  of  the  ETR  analysis.  This  is 
a  printout  of  information  contained  in  the  DBMS  database  with  blank 
columns  for  data  elements  generated  in  these  steps,  which  are  to  be 
entered  into  the  database.  The  printout  is  indexed  on  the  mission 
phase  or  task  title/description  to  assist  identifying  common  mission 
phases,  tasks/objectives,  and  subtasks/subobjectives.  The  printout 
contains  the  number  and  title/description,  which  are  used  to  identify 
the  commonalities;  a  blank  column  for  recording  the  numbers  of  the 
common  mission  phases,  tasks/ob jectives ,  and  subtasks/ subobjectives . 

Form  3  is  used  for  Steps  3.1  and  3.2  of  the  ETR  analysis.  This 
form  is  a  printout  of  information  contained  in  the  DBMS  database,  with 
blank  columns  for  data  elements  generated  in  these  steps,  which  are  to 
be  entered  into  the  database.  The  printout  is  indexed  on  the  number 
data  element,  to  present  a  hierarchial  list.  The  printout  should  be 
limited  to  the  initial  occurrence  of  each  element  to  prevent  analyzing 
common  mission  phases,  tasks/objectives,  subtasks/subobjecti ves 
repeatedly.  The  printout  contains  the  number,  title/description,  crew 
positions,  and  the  initials  of  the  developer  of  the  task/objective.  If 
the  current  analyst  is  different  from  the  original  developer,  the 
analyst's  initials  can  be  recorded  in  the  developer  column,  separated 
from  the  original  developer's  initials  by  a  comma  or  slash.  Blank 
_olumns  for  criticality  codes  (H,  M,  L)  and  objective  classification 
codes  (1,  2,  3,  4,  5,  6)  are  used  to  record  the  codes  for  each 
task/objective  based  on  the  determinations  of  the  analyst. 

Form  4  is  used  for  Step  2.2  of  the  ETR  analysis.  This  form  is  a 
printout  of  information  contained  in  the  DBMS  database,  with  blank 
columns  for  data  elements  generated  in  this  step,  which  are  to  be 
entered  into  the  database.  The  printout  is  indexed  on  the  number  data 
element  to  present  a  hierarchial  list.  The  printout  should  be  limited 
to  the  initial  occurrence  of  each  element  to  prevent  analyzing  common 
mission  phases,  tasks/objectives,  subtasks/subobjectives  repeatedly. 

The  printout  contains  the  number,  title/description,  crew  positions, 
and  conditions  of  performance.  A  blank  column  for  standards  of 
performance  is  us°d  to  record  the  standards  determined  by  the  analyst 
for  each  mission  phase,  task/objective,  and  subtask/subobjective. 

Form  5  is  used  for  Step  3.5  of  the  ETR  analysis.  This  is  a 
printout  of  information  contained  in  the  database,  with  blank  columns 
for  data  elements  generated  in  this  step,  which  are  to  be  entered  into 
the  database.  The  printout  is  indexed  on  the  number  data  element  to 
present  a  hierarchial  list.  The  printout  should  be  limited  to  the 
initial  occurrence  of  each  element  to  prevent  analyzing  common  mission 
phases,  tasks/objective,  and  subtasks/subobjectives  repeatedly.  The 
printout  contains  the  number,  title/description,  crew  positions, 
conditions  of  performance,  standards  of  performance,  criticality  codes, 
perishability  results,  and  ET  nomination  results.  A  blank  column  for 
ET  implementation  codes  (i.e.,  I,  S,  0  ,Q,  H,  T,  and  X)  is  used  to 


record  the  codes  determined  by  the  analyst  for  each  mission  phase, 
task/objective,  sub task/ subobjective . 

Form  6  is  used  for  Step  3.6  of  the  ETR  analysis.  This  is  a 
printout  of  information  contained  in  the  database.  This  printout  is 
used  to  validate  the  database  contents.  The  printout  is  indexed  on  the 
number  data  element  to  present  a  hierarchial  list.  The  printout  should 
be  limited  to  the  initial  occurrence  of  each  element  to  prevent 
validing  common  mission  phases,  tasks/objectives,  and 
subtasks/ subobjective  repeatedly.  The  printout  contains  the  number, 
title/description,  crew  positions,  criticality  codes,  objective 
classification  codes,  perishability  results,  ET  nomination  results,  and 
ET  feasibility  codes. 

No  forms  are  possible  for  Steps  1.1,  1.2,  1.9,  3.3,  or  3. A,  since 
these  steps  are  either  to  be  done  by  the  DBMS  software  or  are  off-line 
tasks.  The  exception  to  this  is  Step  1.9  because  it  is  en visioned  that 
direct  input  into  the  database  should  be  feasible. 


C-10 


NUMBER  title/description  conditions  position  audit  trail  information 

Source: 


Task  No. 


PRINTOUT  FORM 
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PRINTOUT  FORM  6 


APPENDIX  D 

LIST  OF  ACRONYMS  AND  ABBREVIATIONS 
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AMC 

ARI 

ARTEP,  ARTEPs 

ASA 

ASAP 

C3I 

DBMS,  DBMSs 

DCD 

DOTD 

ECA 

ET 

ETR,  ETRs 
FEA 

FM,  FMs 

FOG-M 

FSED 

HARDMAN 

HFE 

IR&D 

ISD 

JMSNS 

LCSMM 

LSAR 

MAA 

MANPRINT 


U.S.  Army  Materiel  Command 

U.S.  Army  Research  Institute  for  the  Behavioral  and 
Social  Sciences 

Army  Training  and  Evaluation  Plan( s )/Program 
Applied  Science  Associates,  Inc. 

Army  Streamlined  Acquisition  Process 

Command,  Control,  Communications,  and  Intelligence 

Database  Management  System(s) 

Directorates  of  Combat  Development 
Directorates  of  Training  and  Doctrine 
A  specific  Early  Comparability  Analysis  technique 
Embedded  Training 
Embedded  Training  Requirement(s) 

Front-End  Analysis 
Field  Manual(s) 

Fiber-Optic  Guided  Missile 
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